update pv on beta cutoff

[AndrewShort]

do you update the pv on beta cutoff?

I don't, but I'm realizing I should. (on beta cutoff, I do update the hash and killers and history-heuristic table, but not the pv).

I guess if I updated the pv on beta cutoffs, then anytime I do IID, it could return a best move even if it failed high. Presently my IID would only work if it returned an exact score.

Also, if I updated the pv on beta cutoffs, then if the engine runs out of time, it could still choose to play the fail high move instead of throwing it away.

is this correct? Any pitfalls I should be aware of? Any other benefits I didn't think of?

[Ron Murawski]

I don't worry about the pv until I am back at ply zero. When the pv is about to print, I see if there is a fail-high or a fail-low condition. For a fail-low, I print the current move followed by a '?', for a fail-high I print the current move and a '!'. Later, when the fail-high/low gets resolved, I print a normal pv.

If you are using your pv moves for purposes other than printing, then you might want to try a different approach.

Ron

[Karlo Bala]

do you update the pv on beta cutoff?

I don't, but I'm realizing I should. (on beta cutoff, I do update the hash and killers and history-heuristic table, but not the pv).

I guess if I updated the pv on beta cutoffs, then anytime I do IID, it could return a best move even if it failed high. Presently my IID would only work if it returned an exact score.

Also, if I updated the pv on beta cutoffs, then if the engine runs out of time, it could still choose to play the fail high move instead of throwing it away.

is this correct? Any pitfalls I should be aware of? Any other benefits I didn't think of?

If you have cutoff then you are not in PV
Yo should update pv only for scores that are between alpha & beta

[AndrewShort]

do you update the pv on beta cutoff?

I don't, but I'm realizing I should. (on beta cutoff, I do update the hash and killers and history-heuristic table, but not the pv).

I guess if I updated the pv on beta cutoffs, then anytime I do IID, it could return a best move even if it failed high. Presently my IID would only work if it returned an exact score.

Also, if I updated the pv on beta cutoffs, then if the engine runs out of time, it could still choose to play the fail high move instead of throwing it away.

is this correct? Any pitfalls I should be aware of? Any other benefits I didn't think of?

ok, let me back up, since I don't know what I'm talking about

suppose you are in a pv node, you found no best move from hash, so you do a shallow search (IID) with the open window of (alpha, beta). Presently, my code uses the best move from the IID search, but only if the returned score is exact. But what if the IID search failed high? Shouldn't I be able to use the move that failed high as a 'best move' ? If so, I need to know what move failed high.

Similarly, suppose at timeout at the root, the best move so far is a fail high move, couldn't I use that instead of tossing it away, as I do now? If so, I need to know what move failed high.

[AndrewShort]

do you update the pv on beta cutoff?

I don't, but I'm realizing I should. (on beta cutoff, I do update the hash and killers and history-heuristic table, but not the pv).

I guess if I updated the pv on beta cutoffs, then anytime I do IID, it could return a best move even if it failed high. Presently my IID would only work if it returned an exact score.

Also, if I updated the pv on beta cutoffs, then if the engine runs out of time, it could still choose to play the fail high move instead of throwing it away.

is this correct? Any pitfalls I should be aware of? Any other benefits I didn't think of?

ok, let me back up, since I don't know what I'm talking about

suppose you are in a pv node, you found no best move from hash, so you do a shallow search (IID) with the open window of (alpha, beta). Presently, my code uses the best move from the IID search, but only if the returned score is exact. But what if the IID search failed high? Shouldn't I be able to use the move that failed high as a 'best move' ? If so, I need to know what move failed high.

Similarly, suppose at timeout at the root, the best move so far is a fail high move, couldn't I use that instead of tossing it away, as I do now? If so, I need to know what move failed high.

I should clarify that in the IID example, it's purely to get a best move for better move ordering. While in the timeout example, it's to get a best move to play.

[Ron Murawski]

do you update the pv on beta cutoff?

I don't, but I'm realizing I should. (on beta cutoff, I do update the hash and killers and history-heuristic table, but not the pv).

I guess if I updated the pv on beta cutoffs, then anytime I do IID, it could return a best move even if it failed high. Presently my IID would only work if it returned an exact score.

Also, if I updated the pv on beta cutoffs, then if the engine runs out of time, it could still choose to play the fail high move instead of throwing it away.

is this correct? Any pitfalls I should be aware of? Any other benefits I didn't think of?

ok, let me back up, since I don't know what I'm talking about

suppose you are in a pv node, you found no best move from hash, so you do a shallow search (IID) with the open window of (alpha, beta). Presently, my code uses the best move from the IID search, but only if the returned score is exact. But what if the IID search failed high? Shouldn't I be able to use the move that failed high as a 'best move' ? If so, I need to know what move failed high.

For a fail-high you should have a best move. It's only for fail-lows where the returned "best move" is uncertain.

Similarly, suppose at timeout at the root, the best move so far is a fail high move, couldn't I use that instead of tossing it away, as I do now? If so, I need to know what move failed high.

Again, you should know what the best move is on a fail-high and, of course, this is the move to make. You know the move is even better than expected, you just don't have an exact value for it.

It's strange that you do not know the best move when you fail high...

Ron

[AndrewShort]

It's strange that you do not know the best move when you fail high...

Ron

that was my point. How does one remember the best move if the search failed high? If the search returns an exact score, the best move is sitting in your pv (pv is updated on raised alphas, but not if fail high). But if the search failed high, the best move is lost in lala land. Or do you use the pv for that (by updating the pv even on fail highs - that was my original question). My mind is getting warped from all the alpha-beta stuff - I even dream about it. My dreams are recursive - I dream of having dreams...

[Ron Murawski]

It's strange that you do not know the best move when you fail high...

Ron

that was my point. How does one remember the best move if the search failed high? If the search returns an exact score, the best move is sitting in your pv (pv is updated on raised alphas, but not if fail high). But if the search failed high, the best move is lost in lala land. Or do you use the pv for that (by updating the pv even on fail highs - that was my original question). My mind is getting warped from all the alpha-beta stuff - I even dream about it. My dreams are recursive - I dream of having dreams...

I retrieve my pv from the hash table. There's no need to store the pv separately unless you are going to use it for other purposes or if you insist on producing a complete pv.

This is when I update my hash table in the search:

#1: On a fail-high I store the current move info in the hash. It is undoubtedly the best move my engine has found so far for the current position and it is desirable to record this fact. I store this to the hash as a lower bound just before my search returns.

#2: I do *not* store alpha improvements in the hash as the search encounters them unless the engine is at the base ply (ie: ply == 0) and the search is about to go full depth (ie: not null-moving or doing a reduced depth search such as in the IID).

#3: After all moves for a ply are finished I store in the hash alpha improvements as exact and others (non-alpha improvements) as upper bounds.

I didn't even mention recursion!

Ron