Modify hash probing code to pvs

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
hgm
Posts: 23772
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Modify hash probing code to pvs

Post by hgm » Tue Dec 06, 2016 8:52 am

And the other hack is detrimetal to reliability...

Necromancer
Posts: 33
Joined: Wed Nov 23, 2016 12:30 am
Location: Brazil

Re: Modify hash probing code to pvs

Post by Necromancer » Tue Dec 06, 2016 2:32 pm

Ok, thank you.

So I'll just follow the code and see what happens.
The truth comes from inside.
https://github.com/fernandotenorio/Tunguska

User avatar
Evert
Posts: 2923
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: Modify hash probing code to pvs

Post by Evert » Tue Dec 06, 2016 9:37 pm

jdart wrote: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
Posts: 20636
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Modify hash probing code to pvs

Post by bob » Tue Dec 06, 2016 11:39 pm

jdart wrote:If that is a bad design, then Stockfish has a bad design.

--Jon
You simply lose efficiency.

syzygy
Posts: 4457
Joined: Tue Feb 28, 2012 10:56 pm

Re: Modify hash probing code to pvs

Post by syzygy » Wed Dec 07, 2016 12:34 am

hgm wrote: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?

User avatar
hgm
Posts: 23772
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Modify hash probing code to pvs

Post by hgm » Wed Dec 07, 2016 5:57 am

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

User avatar
cdani
Posts: 2104
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Modify hash probing code to pvs

Post by cdani » Wed Dec 07, 2016 7:11 am

hgm wrote: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.

Post Reply