TT bug? or something else

[amanjpro]

What I always do for cold-turkey timeout is return immediately after UnMake(). Then an interrupted node does not get to the code for storing anything in the TT.

If you abort at the start of a node, nodes that are already busy while the timeout occurs do store their result in the hash, but because some of their daughters (those called after the timeout occurred) will return nonsense, their result will be nonsense nevertheless. And it will get stored in the TT. Now this is not very harmful, as the number of nodes that are busy at any time is just the search depth. So you perhaps get 20 corrupted TT entries, and the chances this has any effect on a future search is very small.

I don't think it is that rare... my test shows me that the diff is some ~15 Elos (granted my test is still midway, and the margin is +/-15). But the diff has been kept for the last 1000 games, so I tend to trust it

[Henk]

When in root and you have searched ID move and start with remaining moves then at the root you can accept any move that has a larger value than ID Move even when there was no time left to search some remaining moves at the root!

If there was no time to finish search of ID move then give no result back that is return ID Move plus it's value of previous iteration.

If there is no ID move then don't stop search until you have one.

[amanjpro]

So, the match ended, and the version that doesn't store TT in time trouble wins, granted the diff is just outside the error margin, but at least it proves that it is more beneficial than hurtful:

Code: Select all

Score of zahak_next vs zahak_master: 635 - 558 - 807  [0.519] 2000
...      zahak_next playing White: 346 - 263 - 391  [0.541] 1000
...      zahak_next playing Black: 289 - 295 - 416  [0.497] 1000
...      White vs Black: 641 - 552 - 807  [0.522] 2000
Elo difference: 13.4 +/- 11.8, LOS: 98.7 %, DrawRatio: 40.4 %
Finished match