Quiescent search, and side to move is in check

[Evert]

When I find a mate in qsearch, I back-track to the last ply of normal search. If all moves leading up to the mate were checking moves (which necessarily means they were captures as well). It seemed like a shame to throw away useful information when you have it, but I'm pretty sure the effect on playing strength is unmeasurable.

Another idea may be to expand to a full-width search if all captures result in a mate score, in essence verifying the mate score. I suspect it's one of those things that look great on test positions but don't help at all in real games.

[zullil]

My qsearch starts by evaluating the current position statically, to determine a "stand pat" score.

Never do that when in check. Your stand pat code could look something like this, to handle this problem in a non-messy way:

Code: Select all

int stand_pat = in_check ? -INF : eval();
alpha = max(alpha, stand_pat);
if (alpha >= beta)
    return alpha;

If no captures exist, I return alpha if there are any legal moves at all, and either -MATE_SCORE or STALEMATE_SCORE if no legal moves exist.

It is not so rare that no captures exist. In that case, testing for the availability of legal moves (to find that in 99.9% cases it's a waste of time as neither mate nor stalemate) is overkill.
Instead do as follows:
- if in check generate all legal moves (evasions)
- otherwise generate captures only
If in check and there are no moves generated, then return a "mated in ply" score.

So when in check you detect mates, but when not in check (generating captures only) you will miss the stalemates. But generally don't count too much on the qsearch() to find mates and stalemates, as the standpat option prevents this in most cases (it'll only find mates that result from sequences of captures delivering check so that the opponent can't stand pat for example)

In my main search, if the depth is 1 (ie, one step away from a leaf) and the side-to-go is in check, I increment depth to 2 before recursing, so that qsearch isn't called with the side-to-move in check.
But now it occurs to me that qsearch calls itself recursively, and as implemented currently, might do so with the side-to-go in check (ie, an initial capture has placed the opposing king in check, and now I'm calling qsearch again).

Exactly as you say, the check extension will not save you since qsearch captures can deliver check. But I don't think this is the best way to do the check extension. I don't do it like that. I extend checking moves that verify certain properties, rather than extend when in check. Extending when in check is too costly. Anyway, if your engine is weak this is really a finesse that is not worth discussing yet.

Thanks, Lucas. So many helpful replies.