Modify hash probing code to pvs

[hgm]

And the other hack is detrimetal to reliability...

[Necromancer]

Ok, thank you.

So I'll just follow the code and see what happens.

[Evert]

I believe the idea is that in a typical engine non-PV nodes are searched with different extensions and reductions, and so the score from a non-PV node is less trustworthy than a score from a PV node. For this reason a hash hit from a non-PV node is not allowed to cut off a PV node.

Interesting.

I always reasoned that taking a TT cut-off is allowed iff the search can be expected to give the same result, given the search parameters (other than the search bounds). Of course things like killers and history provide some hidden state that can make the search behave differently (sometimes changing the result when they interact with LMR), but this is an indirect effect. What I hadn't realised is that treating PV and non-PV nodes differently adds an extra parameter to the relevant match parameters (so you get depth and nodetype rather than just depth). Then the condition

Code: Select all

if (depth ok)

becomes

Code: Select all

if (depth ok and node types are compatible)

The second condition can be simplified to only allowing results from PV nodes to cut PV nodes, which is approximately the same as not allowing cut-offs in PV nodes. With that simplification, you don't need to store node type information in the TT, so the code can stay as it was.

The corollary to this is that if you allow cut-offs in PV nodes, then you cannot (rigorously) treat PV and non-PV nodes differently. I had not realised this.

A more accurate test than matching node types would be to examine how the current node would be searched. For instance, if you are in check, perhaps you end up searching PV and non-PV nodes the same way. Then you could allow cut-offs in PV-nodes where the side to move is in check. The added complexity of such a test may not be worth it though.

[bob]

If that is a bad design, then Stockfish has a bad design.

--Jon

You simply lose efficiency.

[syzygy]

And the other hack is detrimetal to reliability...

What other hack is unreliable?

If you search non-PV nodes with more reductions and less extensions that PV nodes, but don't take TT cutoffs in PV nodes, how could what be unreliable?

[hgm]

Not doing PV cutoff makes it far more difficult to solve some positions, like Fine #70.

[cdani]

Not doing PV cutoff makes it far more difficult to solve some positions, like Fine #70.

I have only recently added this of don't take the cut if PV. It was maybe +2 elo in selfplay for Andscacs, but with not enough games to be sure.