LMP in PV nodes

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: LMP in PV nodes

Post by bob »

Michel wrote:
The PV descendant of a non-PV node is just the most plausible refutation of the previous move. The logic applied there is no different than the logic at the root. You may choose to treat the most plausible move differently from others.
What I am trying to say is that the (potential) PV descendant node _is_ different since you are now in a research (the scout search for the parent non-PV move failed high). So you may choose to do the research with less pruning to validate the fail high.

What I am saying is really "theoretically correct" (see my first post in this thread)! Not pruning in PV nodes may compensate for more aggressive pruning in non PV nodes through the PVS mechanism in such a way that the tree value does not change.

Since researches take time, in reality it is a trade off.
Sorry, but this is not "theoretically correct". And somehow we are not talking toward the same point. At any node in the tree, you could reach that point with alpha = beta-1 or with alpha < beta-1, which flags this as non-PV or PV respectively. In one case you reduce/prune less (non-PV) which makes little sense. Why are you searching this path in the first place? Hoping to find a better move? That's my intent. If you have a score of 0.0 for several iterations and then find a move that jumps to +1.0, do you stop searching all other moves completely and just search that one deeper and deeper to verify it won't come crashing down, or do you continue to search other moves hoping for a still better one? If the latter, how does pruning/reducing them more aggressively make any sense, it just makes it HARDER for said node to expose the tactics that require a deeper search to see.

So A recap, more detailed. I am going to use the traditional "left-to-right" search order, which means the left-hand edge of the tree represents the first move searched at each ply, and each node on that edge is a PV node by Knuth/Moore's definition.

So, to start this off, let's search that left-hand edge and we are very cautious about reductions and pruning, generally doing none since this should be a critical path through the tree. Suppose we are going 20 plies deep. At ply=19 we make a move (left-hand-edge, PV node) that takes us to ply=20. Since this is also a PV node we search it carefully. Now we back up to ply 19 and try another move, and when we get to depth 20 again, we are NOT in a PV node, and we reduce more aggressively. The question is, what makes this node any different than the first one at this ply? Are you CERTAIN the first move you searched was best and the move leading to this node is worse? Certain enough to not search it at all?

Once you back up to the root with a score for the first move, which you are now apparently convinced is the best move (something that is only true 4 out of 5 times or so) so you now search the rest of the moves at ply=1, allowing more aggressive reductions and pruning along those pathways than what you allowed along the "best move" path. Is this the right way to discover that this is one of those 18% of the times where the first move is not best and you will change to something else?

So, we are at an interesting point. The first move is not best, but we don't know this until we search all the remaining moves. But we search them less rigorously than we searched the best move. Is this the way to discover a deep tactic, which is why we are doing this search in the first place? What if the remaining moves all fail low because they are searched less carefully and we overlook something better? What if this move fails high due to the aggressive reductions/pruning, but when we re-search using the same guidelines we used for the original best move, it now fails low? Is it better than the original best move? Or do we throw it away?

LMR is something that makes sense at any node. The more moves you search without failing high, the more convinced you should become that no moves will fail high and we are just wasting time searching them. We reduce 'em, reducing 'em more and more as we get farther into the move list, and we introduce error since move ordering can not be perfect. We lose Elo. But then we are able to search deeper because of these reductions, which gains Elo. And the net effect is that the error is more than offset by the depth gain and we see a positive improvement in playing skill. But why does it make sense to reduce moves at some nodes more or less than similarly-ordered moves at other nodes? This is the question I have repeatedly asked. And I am not seeing an answer that addresses this. I want my search to behave the same way, and find the same best move, no matter whether the best move is ordered first or second. Yet this approach will not do that.

I firmly believe, until I see some convincing example or explanation, that treating moves differently based on their order (reductions or pruning) is reasonable so long as they are treated the same no matter where they occur in the tree. Not differently just because they appear in different paths, as opposed to where they appear within a single node.
syzygy
Posts: 5566
Joined: Tue Feb 28, 2012 11:56 pm

Re: LMP in PV nodes

Post by syzygy »

bob wrote:Sorry, but this is not "theoretically correct".
Yes it is.

LMP in "expected cut nodes" is theoretically safe. It will give the same score at the same iteration. The explanation has already been given.

(I am ignoring hashing effects.)
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: LMP in PV nodes

Post by bob »

syzygy wrote:
bob wrote:Sorry, but this is not "theoretically correct".
Yes it is.

LMP in "expected cut nodes" is theoretically safe. It will give the same score at the same iteration. The explanation has already been given.

(I am ignoring hashing effects.)
First, LMP does not apply to "expected cut nodes". You only search one move at such nodes any. It is something that applies at ALL nodes, hence the "late" in LMP. It sounds like you are talking about pure alpha/beta pruning, which is theoretically sound, and which is also NOT related to a move's order in which it is searched. It is based only on proving that the previous move leads to a score that is worse than an earlier move.



It will NOT give the same score at the same iteration unless the first move is actually the best move and no "change of mind" is going to happen. Something a tad difficult to guarantee or even predict since a PV change happens about once out of every 5 iterations.

Also if you ignore hashing, might as well ignore most everything. It is an integral and important part of the search.
syzygy
Posts: 5566
Joined: Tue Feb 28, 2012 11:56 pm

Re: LMP in PV nodes

Post by syzygy »

bob wrote:
syzygy wrote:
bob wrote:Sorry, but this is not "theoretically correct".
Yes it is.

LMP in "expected cut nodes" is theoretically safe. It will give the same score at the same iteration. The explanation has already been given.

(I am ignoring hashing effects.)
First, LMP does not apply to "expected cut nodes". You only search one move at such nodes any. It is something that applies at ALL nodes, hence the "late" in LMP. It sounds like you are talking about pure alpha/beta pruning, which is theoretically sound, and which is also NOT related to a move's order in which it is searched. It is based only on proving that the previous move leads to a score that is worse than an earlier move.
No, I am talking about PVS. An expected cut node is a node at an odd number of ply from the last PV node visited. Applying LMP to such a node means skipping the last few moves if the earlier moves do not cut.

Theoretically sound. Has been explained too many times already. The re-search fixes things.
Henk
Posts: 7220
Joined: Mon May 27, 2013 10:31 am

Re: LMP in PV nodes

Post by Henk »

syzygy wrote:
bob wrote:
syzygy wrote:
bob wrote:Sorry, but this is not "theoretically correct".
Yes it is.

LMP in "expected cut nodes" is theoretically safe. It will give the same score at the same iteration. The explanation has already been given.

(I am ignoring hashing effects.)
First, LMP does not apply to "expected cut nodes". You only search one move at such nodes any. It is something that applies at ALL nodes, hence the "late" in LMP. It sounds like you are talking about pure alpha/beta pruning, which is theoretically sound, and which is also NOT related to a move's order in which it is searched. It is based only on proving that the previous move leads to a score that is worse than an earlier move.
No, I am talking about PVS. An expected cut node is a node at an odd number of ply from the last PV node visited. Applying LMP to such a node means skipping the last few moves if the earlier moves do not cut.

Theoretically sound. Has been explained too many times already. The re-search fixes things.
But in these "expected cut nodes" you probably don't win much ELO for a research is expensive and they don't occur very frequently. I fail low in these nodes if hash says it didn't fail high at lower depth (also value from hash should be a bit less beta), but I don't know if it is a gain or not.
Last edited by Henk on Mon Jan 05, 2015 1:33 pm, edited 1 time in total.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: LMP in PV nodes

Post by Evert »

Correct me if I'm wrong, but I didn't see any claim that LMR/LMP is a large win in expected CUT nodes or whether it is more appropriate there than in ALL nodes, just that it is theoretically safe to do it there in that particular circumstance.

I didn't go through the presented explanation for as to why that is in detail, but it looked reasonable when I tried to follow it in my head.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: LMP in PV nodes

Post by Evert »

bob wrote:
Evert wrote:
bob wrote: 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.
That was my initial thinking as well, but I'm not convinced anymore that it makes sense: suppose you do include a null-move search in the PV. If the null-move fails high, then you take the cut-off, which (eventually) triggers a re-search with a larger window to keep the null-move in window. If it doesn't fail high, you just search the remaining moves as normal. At no point do you get a null-move in the PV at the end of an iteration (you might get it for an intermediate result, but that's not necessarily a problem although it might look a bit odd if you display that to the user). Am I missing something?

What would not surprise me is if a null move is simply a waste of time in a PV node, but I haven't tested this in any way. Of course, one could do something with the information from the null-move search (change move-ordering, or threat extensions) and those may help. Again, not something I've tried at (expected) PV nodes.
You would have to special-case it. But I ran millions of test positions and in general, null-move everywhere increased the overall tree-size measurably. These were fixed-depth searches so that nodes could be compared. This is not a significant issue in terms of Elo, but it has a measurable effect.
Ok, so if I understand you correctly, then allowing a NULL move in an (expected) PV node is not so much incorrect (because a NULL move should never be part of the PV) but is rather a waste of time?
Henk
Posts: 7220
Joined: Mon May 27, 2013 10:31 am

Re: LMP in PV nodes

Post by Henk »

Evert wrote:Correct me if I'm wrong, but I didn't see any claim that LMR/LMP is a large win in expected CUT nodes or whether it is more appropriate there than in ALL nodes, just that it is theoretically safe to do it there in that particular circumstance.

I didn't go through the presented explanation for as to why that is in detail, but it looked reasonable when I tried to follow it in my head.
If it is not an ELO gain then it is not interesting to spend much time on it. You might as well ignore that case.
Last edited by Henk on Mon Jan 05, 2015 1:43 pm, edited 1 time in total.
Rein Halbersma
Posts: 741
Joined: Tue May 22, 2007 11:13 am

Re: LMP in PV nodes

Post by Rein Halbersma »

bob wrote: First, LMP does not apply to "expected cut nodes". You only search one move at such nodes any.


No, LMP applies to expected CUT-nodes. With perfect move ordering, you expect to search only 1 move to get the expected fail-high. So if by the last moves, you haven't failed high yet, you simply prune them, faill low here, and fail high one ply upwards. If that fail high is at an expected PV-node, you research with a full window and without LMP (and at an ALL-node, the fail-high will eventually bubble up towards a PV-node, causing a research higher-up in the tree)

If your move ordering at CUT nodes is any good, you should save effort and find a better move over your current PV quicker than without LMP. On occasion, the research might discover a very late move that would have produced the initial fail-high you were looking for, hadn't you done the LMP on the previous null-window search. That's the tradeoff.
Rein Halbersma
Posts: 741
Joined: Tue May 22, 2007 11:13 am

Re: LMP in PV nodes

Post by Rein Halbersma »

syzygy wrote: No, I am talking about PVS. An expected cut node is a node at an odd number of ply from the last PV node visited. Applying LMP to such a node means skipping the last few moves if the earlier moves do not cut.

Theoretically sound. Has been explained too many times already. The re-search fixes things.
Just a side question: what do you do with your node classification? Do you have PV/CUT/ALL and do different things at those 3 node types, or do you do PV/NonPV? In particular, do you treat CUT/ALL nodes differently wrt LMR? If so, how?