Detecting stalemate in quiescence search

[zd3nik]

Does anybody try to detect stalemate positions in quiescence search - to prevent returning stand-pat score when in stalemate?

In one of my older engines that always generated one move at a time I would verify in qsearch that it could generate at least one legal move. But that kind of move generator is really slow (at least the way I implemented it).

I'm thinking about a trying a couple different ideas to solve this problem but I don't want to waste the time if this is a problem that is already solved (or doesn't need to be solved).

So I'm wondering two things:

1. Has anyone figured out a (really fast) way to verify a position is *not* stalemate?
2. Is it worth doing in the first place? e.g. does standing pat in qsearch when it's stalemate lead to problems in the real world? Or is the occurrence so rare that it's masked by the next depth iteration 99.999% of the time?

[hgm]

I don't expect this to have any effect on Elo. Stalemates in practice only occur in the late end-game. Basically in tablebase situations.

[Sven]

Does anybody try to detect stalemate positions in quiescence search - to prevent returning stand-pat score when in stalemate?

In one of my older engines that always generated one move at a time I would verify in qsearch that it could generate at least one legal move. But that kind of move generator is really slow (at least the way I implemented it).

I'm thinking about a trying a couple different ideas to solve this problem but I don't want to waste the time if this is a problem that is already solved (or doesn't need to be solved).

So I'm wondering two things:

1. Has anyone figured out a (really fast) way to verify a position is *not* stalemate?
2. Is it worth doing in the first place? e.g. does standing pat in qsearch when it's stalemate lead to problems in the real world? Or is the occurrence so rare that it's masked by the next depth iteration 99.999% of the time?

In quiescence search I test for stalemate in positions where the moving side has a lone king, which is practically the most important case. This means that in almost all qsearch positions during a game no stalemate testing is performed. In other cases it would also be too much effort in my view. King and only blocked pawns is frequent as well but you would not want to perform a regular pawn move generation in qsearch since that is usually the most complex part of move generation at all due to three special pawn move types.

But even without this check I see no severe problem for playing strength. Standing pat and missing a stalemate often means you are down in material but the opponent has just captured your last piece and your king has no legal move. But in practice it should be quite rare that there is no better capture for the opponent than that one so returning a stand-pat score would not do much harm very often. Nevertheless, sometimes you could get a wrong score in some qsearch subtree but statistically this will almost never affect the root.