When depth is zero

[Mike Sherwin]

In the search when depth is zero Qsearch is called. And then we just standpat if the static score >= beta. It is just assumed that there will be a move to protect that that score. But what if that assumption is wrong? Then we have an erroneous score in the search tree at what could be a very important place. I understand that we must rely on assumptions to narrow the search and to prevent search explosion. It might also be that there are bad places to make such assumptions and that transitioning from regular search to quiescence search might be one of them.

I simply suggest not calling Qsearch from Search if eval >= beta. It does not seem to cause any noticeable search explosion.

[hgm]

Usually you don't have eval yet, before you call QSearch. If you had, you would calculate it twice, as the QSearch you call treats the same node as the full-width search from which you call it. Of course you could design things such that you pass eval to QSearch. I usually design things such that there is no separate QSearch; the code of the one and only search routine I is used for both. It starts with searching captures, and if those do not cut, it only continues with non-captures when d > 0.

[Mike Sherwin]

Usually you don't have eval yet, before you call QSearch. If you had, you would calculate it twice, as the QSearch you call treats the same node as the full-width search from which you call it. Of course you could design things such that you pass eval to QSearch. I usually design things such that there is no separate QSearch; the code of the one and only search routine I is used for both. It starts with searching captures, and if those do not cut, it only continues with non-captures when d > 0.

Still someone should try it.

[Ras]

I simply suggest not calling Qsearch from Search if eval >= beta.

The most important situation where this would even be relevant is if you're in check, and you shouldn't dive into QS while being in check anyway.

[Mike Sherwin]

I simply suggest not calling Qsearch from Search if eval >= beta.

The most important situation where this would even be relevant is if you're in check, and you shouldn't dive into QS while being in check anyway.

Still someone should try it.

[jhellis3]

Out of curiosity, what do you do instead of Qsearch when in check?

[Ras]

Out of curiosity, what do you do instead of Qsearch when in check?

When being in check and the depth is below 6 plies, I don't decrease the depth for the next level. Hence, I continue normal search.

[Desperado]

In the search when depth is zero Qsearch is called. And then we just standpat if the static score >= beta. It is just assumed that there will be a move to protect that that score. But what if that assumption is wrong? Then we have an erroneous score in the search tree at what could be a very important place. I understand that we must rely on assumptions to narrow the search and to prevent search explosion. It might also be that there are bad places to make such assumptions and that transitioning from regular search to quiescence search might be one of them.

I simply suggest not calling Qsearch from Search if eval >= beta. It does not seem to cause any noticeable search explosion.

Well, let's say you have a good reason to ignore the nullmove observation and you really want to confirm that there is a move
that is above beta.

Indeed, such situations do exist but will be handled within the QS, like evasion nodes where many engines ignore the stand pat.
The idea can be extended to other strong threats that can be quickly detected, most of the time by the eval function.
(hanging pieces, passed pawn before promoting, just to give ideas).

So, my suggestion would be to enter the Qsearch-Node. Ignoring the stand pat and checking the captures and checking moves which is usually done. Of course you can try other interesting moves too, which are included in your general QS concept.

Finally to extend the horizon node or ignoring stand pat in qs (which are very different actions) should be based on a static information (like threats), but not because of an abstract score. In both cases you can search for a "validation" (a move), but the QS Node will be cheaper in general than a one ply node (horizon node).

I would like to give you another idea. Of course you can change the formula to "score >= beta +- margin"
That way you can be more risky or you can also go on the safe side. Based on the margin you can take all actions and can handle the nullmove observation more flexibel. (that can be used for nullmove pruning and eval pruning too of course. At the end stand pat can be seen as simplified form of the nullmove technique)

[Karlo Bala]

In the search when depth is zero Qsearch is called. And then we just standpat if the static score >= beta. It is just assumed that there will be a move to protect that that score. But what if that assumption is wrong?

The bigger the search tree the less chance that something unexpected will happen, since there will be more siblings with the same assumption. Other than that, having a move at disposal is a big edge. We know that because we use the null-move heuristic, and it is one of the most powerful heuristic in computer chess. The null-move heuristic also tells us much of the true nature of chess. The stand pat is just the special (degenerative) case of the null-move heuristic.

There are some very old posts, I think from Amir Ban, where he explains that it is possible to make the engine stronger by searching less. In modern engines, there are many places where such an approach is taken. For example, at depths 1 or 2 don't put a piece on the attacked square (and/or exclude bad captures). Most of the time such an approach shrinks the search tree and makes the engine stronger even with a fixed depth search.

[hgm]

Out of curiosity, what do you do instead of Qsearch when in check?

When being in check and the depth is below 6 plies, I don't decrease the depth for the next level. Hence, I continue normal search.

In QS I also do a d=1 search (i.e. also search non-capture evasions) when in check. Except in microMax, for the simple reason that it doesn't know when it is in check, in QS.