The current approach of treating them differently introduces some interesting hashing inconsistencies. In hashing, all we use to identify a position is the Zobrist signature and then the depth to see if the results are usable at the current node. If you take position P and search it in a non-PV context and reduce it more aggressively, how do you stop from using that hash hit in the PV where you will reduce less aggressively.
It is possible to deal with the hashing inconsistency by recording the node type in the hash table (this is not an outlandish idea as somebody once wrote on the SF forum that this is what Ippolit does).
The "contract" that makes PVS give the right tree value is
(1) A lower bound returned by a CUT node should be correct.
(2) An upper bound returned by an ALL node should be correct.
(3) A value returned by a PV node should be correct.
This tells you how to use bounds from the hash table (assuming you recorded the node type).
Ideas=science. Simplification=engineering.
Without ideas there is nothing to simplify.
The "contract" that makes PVS give the right tree value is
(1) A lower bound returned by a CUT node should be correct.
(2) An upper bound returned by an ALL node should be correct.
(3) A value returned by a PV node should be correct.
More precisely if (1,2,3) hold for the child nodes of a node then the PVS update rules ensure that they hold for the node itself.
I hope it's correct .
Ideas=science. Simplification=engineering.
Without ideas there is nothing to simplify.
LMR except in PV : -48 elo
LMR everywhere : 0 elo
No LMR : -140 elo
Qualitatively LMP behaves the same as in the previous test even though the actual numbers are different. It can also be seen that LMR is more important than LMP in texel.
It is interesting to note that while LMP hurts in PV nodes (-8 elo), LMR is actually a big win in PV nodes (+48 elo). Can theory explain this difference between LMR and LMP behavior?
Can theory explain this difference between LMR and LMP behavior?
I assume you mean this as a rethorical question
Theory cannot even predict why doing LMP only at CUT nodes (which is "theoretically safe" in the sense that it does not change the tree value) would result in an elo gain/loss (because of the time it takes to do researches).
In general a better theoretical framework for predicting the performance of tree search algorithms (based on an inaccurate static evaluation function) is sorely missing.
Ideas=science. Simplification=engineering.
Without ideas there is nothing to simplify.
Can theory explain this difference between LMR and LMP behavior?
I assume you mean this as a rethorical question
I did not, but I did suspect that the answer would be "no". Maybe the question should have been "Can hand-waving arguments be made to explain this difference between LMR and LMP behavior?"
Another question is if the behavior in texel can be reproduced in other engines.
Michel wrote:(1) A lower bound returned by a CUT node should be correct.
(2) An upper bound returned by an ALL node should be correct.
(3) A value returned by a PV node should be correct.
This tells you how to use bounds from the hash table (assuming you recorded the node type).
So an upper bound returned by a CUT node can still be used, but only if the node is again searched as a CUT node. Same for lower bounds returned by ALL nodes.
I wonder what Elo loss such a restriction on the use of hash scores would give in an engine that does not treat CUT and ALL nodes differently (in terms of reductions etc.)
The current approach of treating them differently introduces some interesting hashing inconsistencies. In hashing, all we use to identify a position is the Zobrist signature and then the depth to see if the results are usable at the current node. If you take position P and search it in a non-PV context and reduce it more aggressively, how do you stop from using that hash hit in the PV where you will reduce less aggressively.
It is possible to deal with the hashing inconsistency by recording the node type in the hash table (this is not an outlandish idea as somebody once wrote on the SF forum that this is what Ippolit does).
The "contract" that makes PVS give the right tree value is
(1) A lower bound returned by a CUT node should be correct.
(2) An upper bound returned by an ALL node should be correct.
(3) A value returned by a PV node should be correct.
This tells you how to use bounds from the hash table (assuming you recorded the node type).
Doesn't work. There are nodes BELOW the node where you got a hash hit. How do you account for them as well?
How does the three steps you gave above tell you anything at all? By themselves, they are exactly what everyone does. A CUT node can ONLY return a lower bound, an ALL node can ONLY return an upper bound, and an EXACT (PV) node can only return an exact score. Where is the type of node being used anywhere in that? Under what circumstances could you get anything other than a LOWER bound on a CUT node?
Even worse, you STILL have the problem with position P1 and P2 being reached in the table, where P1 = P2 except that it occurs in a different sub-tree. And searched with different pruning/reduction limits.
The "contract" that makes PVS give the right tree value is
(1) A lower bound returned by a CUT node should be correct.
(2) An upper bound returned by an ALL node should be correct.
(3) A value returned by a PV node should be correct.
More precisely if (1,2,3) hold for the child nodes of a node then the PVS update rules ensure that they hold for the node itself.
I hope it's correct .
It isn't. If you reach the same position where one of the above applies, but we are talking about the node BELOW the current node, then the current node could be PV or non-PV, which means the node below this position was searched with different pruning/reduction limits, giving inconsistent results. That is just one of the problems I have described.
Michel wrote:(1) A lower bound returned by a CUT node should be correct.
(2) An upper bound returned by an ALL node should be correct.
(3) A value returned by a PV node should be correct.
This tells you how to use bounds from the hash table (assuming you recorded the node type).
So an upper bound returned by a CUT node can still be used, but only if the node is again searched as a CUT node. Same for lower bounds returned by ALL nodes.
I wonder what Elo loss such a restriction on the use of hash scores would give in an engine that does not treat CUT and ALL nodes differently (in terms of reductions etc.)
That's a good question. I can't test it easily since I don't treat node types differently, and I really don't want to look at the stockfish code to (a) treat all nodes the same and then (b) store the node type and limit matching to similar node types. But something tells me that (b) is bad, because almost any restriction that limits hash hits seems to hurt.
.