This cannot be answered with universal generality, because it depends on the engine in many ways. E.g. which fraction of the hash moves will be moves from other positions due to key collisions or SMP corruption. This obviously depends on how many key bits you store in the entry, and whether you already take more general measures against corruption (such as Bob's lockless hashing, or accessing entries atomically). Since in any good design of your hash table the frequency of faulty hash moves will be very small, things you must do in every node to identify them very easily can become counter-productive (in time of speed / Elo). In general it is bad practice to apply cures that are worse than the disease. Crashing is a pretty bad disease, though, so you would probably do anything to prevent occasional crashing, even when this would cost Elo (under the assumption that a crash would be counted as any other loss). But I could even imagine there are people who prefer the Elo over the label 'crash-free', no matter how much worked up others woould get about this.Terje wrote: ↑Fri Feb 14, 2020 4:28 pmGood summary, except the outstanding issue (to me anyway) is which approach - pseudo legal test or handle making/unmaking illegal moves stably - is best. Not in the sense that it's "correct coding practice" or whatever, but best for speed / strength of the engine. Maybe I'll try the latter approach some day to compare, but if someone does in the meantime I'd love to hear the results
Which problems with the hash move could cause crashing, and how expensive it would be to test for those will very much depend on what info is included in the hash move, (like: does it contain moved piece or capture victim?), and how your MakeMove / UnMake uses that information. Bob apparently encodes the moved piece, and since I suppose he would not do that if it wasn't used somewhere, e.g. in UnMake to put the piece back, a mismatch here would cause permanent damage to the game. But on the upside is that it can be helpful in weeding out faulty hash moves.
So you would have to do an analysis of what defects in a hash move could cause UnMake to not precisely undo MakeMove, and how MakeMove could produce invalid game states that could cause crashing deeper in the tree. And for each such condition you can then investigate whether the problem can be solved in MakeMove / UnMake by doing things differently, or whether it would be cheaper to add an extra test to intercept hash moves that cause the problem. E.g. if your move encoding contains the capture victim, and UnMake would put back the piece from the move, this would fail if the hash move did not specify the victim that was actually there. But you could disarm that by having MakeMove remember the piece that was captured, and have UnMake put back that. Reading the piece from the board might be just as efficient as extracting it from your move encoding.