Michel wrote:I don't disagree at all, but what does that have to do with treating PV vs non-PV nodes differently?
In the post after the one you are answering I explained it.
And as a note, your definition of CUT/ALL is wrong
A definition is never wrong
The definition of CUT/ALL I gave reflects how search errors are propagated to the nearest PV node which is important for PVS since scout searches are researched if they fail high but not if they fail low.
Don Dayley once wrote that Komodo also uses this definition (for the same reason). I do not know if this is still true.
If you read my Ph.D. dissertation, this idea was a 1987 thing I used in Cray Blitz to help choose a split point. I sometimes had to split before the first branch of a node had been searched, so this ALL/CUT parity was a specific starting point (but one which had to be modified since ALL/CUT is NEVER correct in every place.
Your "propagate" really overlooks a lot of things. First, non-PV nodes directly influence PV nodes via the transposition table.
But the question still remains unanswered, what theoretical justification is there for reducing or pruning differently based only on the criteria "is alpha == beta -1 or not?" Of course that definition only works for PVS, but that is what everyone is using so it seems like a good way of defining a PV node in the classic sense, even if it is quite often wrong due to improper move ordering.
Here is a more specific example question. Suppose you have searched a root move completely except for the very last node. Why would you reduce/prune MORE on that very last node, just because this position comes from the first move at the root vs the second move at the root?
The only viable exception to the PV vs non-PV node treatment is with null-move search, since doing a null-move at a PV node doesn't help, as a null-move is not legal and can not be propagated back to the root. So you do the search and if it fails low, you do nothing anyway, just as always, if it fails high, you still do nothing since you can't back up the null-move as best under any circumstance. But I have not seen any other example of where treating PV / non-PV nodes differently is sound.
The most often-quoted answer is "it seems to work." (for some, although many of us have tested it and found it to be worse). Just because something works is NOT a good reason to use the idea unless the idea has a rational justification. I've had plenty of bugs where fixing them actually hurt performance, but I was not going to leave the bugs in because they were bugs. My approach has always been "if it is theoretically sound but doesn't work, figure out why and fix it" or "if it is theoretically unsound but does work, figure out why and fix it." I don't like witchcraft/superstition solutions.
