Modify hash probing code to pvs
Moderators: hgm, Rebel, chrisw
-
- Posts: 27817
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Modify hash probing code to pvs
And the other hack is detrimetal to reliability...
-
- Posts: 33
- Joined: Wed Nov 23, 2016 1:30 am
- Location: Brazil
Re: Modify hash probing code to pvs
Ok, thank you.
So I'll just follow the code and see what happens.
So I'll just follow the code and see what happens.
The truth comes from inside.
https://github.com/fernandotenorio/Tunguska
https://github.com/fernandotenorio/Tunguska
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Modify hash probing code to pvs
Interesting.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.
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)
Code: Select all
if (depth ok and node types are compatible)
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.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Modify hash probing code to pvs
You simply lose efficiency.jdart wrote:If that is a bad design, then Stockfish has a bad design.
--Jon
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: Modify hash probing code to pvs
What other hack is unreliable?hgm wrote:And the other hack is detrimetal to reliability...
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?
-
- Posts: 27817
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Modify hash probing code to pvs
Not doing PV cutoff makes it far more difficult to solve some positions, like Fine #70.
-
- Posts: 2204
- Joined: Sat Jan 18, 2014 10:24 am
- Location: Andorra
Re: Modify hash probing code to pvs
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.hgm wrote:Not doing PV cutoff makes it far more difficult to solve some positions, like Fine #70.
Daniel José - http://www.andscacs.com