mjlef wrote:A refinement is that if the depth is less than whatever the null reduction value, you can safely store with the depth reduction value. For example if depth=2, and you would reduce a null move by 4 (R=3 plus the normal 1 ply you would reduce) then you can save it with depth=4. I only save though if the has entry has no move in it. Not well tested but it seems to keep move ordering better, since a null move search returns no real "move" for the current since two moves in a row could lead to illegal moves for the current side in the regular search.
How does this not cause search inconsistencies? You store "fail high" two piles deeper than justified, you can get a fail high caused by that entry, but the re-search will fail low since it can't see the extra 2 plies, not that we know that the 2 plies do anything anyway...
With the "entry has no move" you are obviously not talking about the thing you are fixing to store, since a null-move search would not have a best move to store anyway. Are you talking about the entry you are about to overwrite? IE don't overwrite if the replaced entry has a best move?
Depth bootstrapping is completely consistent. If you normally have R=2, and a d=1 node fails high on its null-move search, you know for sure that exactly the same tree would have been searched when the requested depth had been d=3. So it is consistent to store with draft 3, so that future hits on it that request d=3 will be immediately satisfied from the hash. Rather than having to do the extra hash access for the position after null move, requesting depth 3-1-R = 0, to see there that draft 0 was indeed available, and causes the null move to fail high.
Similar for QS nodes that fail high on a capture (which are good for d=1 hash hits), or QS nodes that fail low and where all non-captures were futile (also good for d=1). Or, best of all, QS nodes that fail high on a move leading to a node where all non-captures were futile, which are good for d=2 hash hits.
