SF search inconsistency

[jwes]

But regarding this problem I find it interesting that TT works in general, even in positions where repetitions are very likely.

What happens is that the program encounters a position a second time, saves a draw value in the TT with a depth of 1, eventually goes back up the tree to where it encountered the position the first time and overwrites the TT entry with one with greater depth (which suggests that not writing TT entries for repeated positions is a good idea). Another factor is that nearly always the draw value is not propagated up the tree, since, if the position is not a draw, either one side made a mistake by repeating the position or the other side made a mistake by allowing the repetition.

[bob]

But how do you draw the line? For instance if there is node at depth = 5 which one grand-grand-grand-grand-child is repetition draw, do you still want to avoid saving value to TT?

Yes. It's the only correct way I guess.

How about a node where all of the (non-losing) children lead to draws by repetition?

None of this solves the problem, however. You can store an entry that does not lead to a repetition, and look it up in a position where it would lead to one, since path information is not hashed...

But there would be at most a two-time repetition in the path. By rule this is not a draw. Therefore retrieving a non-draw value from TT should be OK.

How can you tell whether it is 2 or 3? Hashing grafts things from A to B in the tree. And then that gets grafted somewhere else. It would be easy to get a score backed up that actually represents a search thru a repetition. And all you know is (sometimes) it is a repetition. Doesn't matter whether it is 2 or 3. If you miss a 2, the next hit can miss a 3.

There really is no solution to this except to include path information in the hash, which effectively kills hashing.

My trial to avoid retrieving wrong draw scores from TT alone killed the program performance. Theoretically it would be possible to avoid missing 3-fold repetitions, but that would kill performance even more. So it's a zombie approach anyway.

But regarding this problem I find it interesting that TT works in general, even in positions where repetitions are very likely.

The issue is a "critical path". For a given search, there is usually one critical path (the PV). For a 20 ply search, this is about 20 positions. Out of hundreds of millions. These "oddities" have to happen along the critical path or they have very little chance of affecting the move the thing finds best (yes, a move not on the critical path can cause incorrect pruning around a move that is, but in general this idea holds.)