Cutoffs in Quiescence Search

[jfern2011]

Upon entry into quiescence search, I've seen people compute a "stand-pat" score for the position, and if this value is greater than beta, perform a cutoff (returning beta). How on earth is this correct? You can't rely on the stand-pat score if, say, the position favors white by a queen, but his queen is about to be captured.

Thanks,
Jason

[elcabesa]

at some point you have to stop in the search and you forgot that when you evaluate standpat is your turn to play.

so you are betting that if your static eval is better than beta and it's your turn, you'll be able find some move that will improve the situation.

more information here
https://chessprogramming.wikispaces.com ... nce+Search

[hgm]

You can't rely on the stand-pat score if, say, the position favors white by a queen, but his queen is about to be captured.

The point is that none of your pieces can be captured, because it is not the opponent's turn. You are the one that can do the capturing. But why would you, if what you have now is already good enough to get a cutoff?

[Sven]

Upon entry into quiescence search, I've seen people compute a "stand-pat" score for the position, and if this value is greater than beta, perform a cutoff (returning beta). How on earth is this correct? You can't rely on the stand-pat score if, say, the position favors white by a queen, but his queen is about to be captured.

Qsearch is never perfect. It is meant to find out with very limited effort whether the side to move at the full-width search horizon can win material or improve the position otherwise. Hanging pieces, e.g. by a fork, are not always detected so they should perhaps be addressed by the eval.

In this example:
[d]1k6/1r1p4/1rp5/1n4p1/R1RNP1P1/2P2PKP/1P6/8 w - - 0 1[/d]

during qs you could calculate Nxb5? cxb5 (quiet) and now think white is ahead by three pawns, while in fact it loses a rook. This can't be found by qs.

[hgm]

Problems that cannot be solved by having the move are quite rare in the tree. So spending time to detect them and then spending more time to find a solution for them is almost always wasted time: you do a lot of stuff, and in the end it changed nothing. If you do that in every QS node, it might cost you a ply of full-width thinking, and in that extra ply you might have recognized the unsolvable problems anyway.

Another issue is that the leaves of a typical search tree are mostly very unnatural positions, where both sides have multiple hanging pieces. Normally multiple hanging pieces means you will lose something, as you can only save one. But if the opponent has them too, you just try to capture material faster than you lose it. Trying to find solutions based on common Chess wisdom for threats against you are counter-productive in these positions.

[jfern2011]

I wasn't thinking about whose turn it is to play at the time the static eval is performed. Now that you mention it it seems really obvious. Thanks!

[Teemu Pudas]

Upon entry into quiescence search, I've seen people compute a "stand-pat" score for the position, and if this value is greater than beta, perform a cutoff (returning beta).

Greater than or equal to beta.

[Evert]

Upon entry into quiescence search, I've seen people compute a "stand-pat" score for the position, and if this value is greater than beta, perform a cutoff (returning beta).

Greater than or equal to beta.

More generally, you can raise alpha by the stand-pat score and then take a normal beta cutoff.
Of course most nodes in a PVS search are searched with a null-window, so this works out to the same thing.