Spite checks

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

User avatar
hgm
Posts: 27788
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Spite checks

Post by hgm »

n the face of an unavoidable mate, the losing engine typically reverts to 'spite checks', in order to delay the mate, or push it over the horizon. Especially if the spite check is a silly scarifice, this is rather counter-productive to play it in the root. It makes it in no way more difficult for a computer opponent to find the mate (this simply grabs the offered material in order to resolve the check, and will then see the mate on the next move, if it had not seen it already). And agains humans, which might not have seen the mate, giving up the material just makes sure you lose even when he did not see it.

But deeper in the tree spite checks might also hurt. In particular when there is the choice to prevent the opponent to acquire an unavoidable checkmate against you, or grabbing some material. A spite check at the end of the branch might then push the mate beyond the horizon, making the grabbing of the material seem a good deal. E.g. an unavoidable checkmate might be delayed 6 ply by trading a Knight with check, sacrificing a Bishop on the Pawn shield, and then a Queen.

[d]2k2b1r/pppq1ppp/3n1p1r/3BnN2/2NpP3/1P1P1bP1/P1QP1P1P/R3BRK1 w - - 0 1
If white tries to grab the Exchange here by 1.Nxh6, then 1... Qh3 seals his fate. But it takes squite some depth before it actually sees that it will be mated, and the initial spite checks are not costly enough to deter it from grabbing the Rook (2. Nxc6+ Bxc6 {neutral} 3. Bxb7 Kxb7 {P for B}). Of course the standard check extension helps, but it does not completely neutralize the spite checks, and each of them still eats away one ply of depth.

Now in Chess this is not that much of a problem, as it is not often that you have a large number of cheap spite checks available. But in games where pieces can be dropped, such as Crazyhouse or Shogi, you often have several Pawns or Knights in hand, which can be easily dropped with check. This tends to mask the severity of a mate threat against you, so that engines keep hunting for material until it is too late, and they are doomed (where in the subsequent moves you see the material advantage they built then erode away spectacularly, as it has to resort to more and more expensive spite checks to keep the unavoidable mate beyond the horizon).

So I wonder if there would not be a method to solve the method of spite checks in general (which no doubt would contribute more Elo in games with drops than in Chess, but still might add some Elo even in the latter). One idea is that sacrificial checks at remaining depth = 1 are suspect. The evasion will be extended, but if there is an evasion (i.e. the check was not checkmate), why would you play them? When a check at d=1 results in a score lower than the current evaluation, even when it scores above beta, and all non-checks score below beta (e.g. because they get you checkmated in the first ply of QS), it is very likely that the checking branch abuses the privilege to stand pat in the face of an undefensible mate threat. Perhaps even a check that gains material should be suspect if all non-checks get you mated?

This suggests the following search strategy: if at d=1 the null move scores below the current eval, we prune all checks by giving them a default score mated-in-100 (say). In cases where the current eval is below alpha, this will require artifically lowering the alpha of the null-move search to just below the current eval, to prevent an automatic fail low of the null move by an opponent stand-pat after it (which of course normally would have been a reason to not try null move at all, when curEval <= alpha).

This, however, would also prune checks that really solved the (mate) threat, but accidentally were also checks. So perhaps rather than pruning the checks, they should be searched under non-standard rules, where the opponent King is 'granted immunity' (and no check extension is being awarded).
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Spite checks

Post by bob »

I think the biggest problem is "value = MATE - ply". Which favors deeper mates. Looks to me to be a difficult problem to solve, and it once again returns to the problem of "discernability" when talking about humans (can the human actually see the threat the program is so viciously trying to escape from?)

In any case, so long as "ply" is factored in to compute a checkmate score, I am not sure there is anything really useful to do. Perhaps you might compute some "horizon" that you don't believe your opponent can see beyond, you could cap mate scores at that point, and perhaps fold in material score so that you prefer a mate which is beyond this horizon AND which preserves the best material score for you...
User avatar
hgm
Posts: 27788
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Spite checks

Post by hgm »

That is not really the point I wanted to address this time. I worry about the case where a series of spite checks push the mate over the horizon, and the part of the spite checks that are within the horizon are not expensive enough to deter the engine from accepting a poisoned sacrifice. So how the mates are scored is not really relevant, because in any case the branch with the spite checks will be preferred.

So my idea was: if you cannot see the mate, just assume there is one.

That does not really help if the root is a forced mate against you, but it would deter you from taking a poisoned piece with the plan to sacrifice part of that gain back to push the mate out of view.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Spite checks

Post by bob »

hgm wrote:That is not really the point I wanted to address this time. I worry about the case where a series of spite checks push the mate over the horizon, and the part of the spite checks that are within the horizon are not expensive enough to deter the engine from accepting a poisoned sacrifice. So how the mates are scored is not really relevant, because in any case the branch with the spite checks will be preferred.

So my idea was: if you cannot see the mate, just assume there is one.

That does not really help if the root is a forced mate against you, but it would deter you from taking a poisoned piece with the plan to sacrifice part of that gain back to push the mate out of view.
Harder problem. Hard to think of a reasonable way to "peek over the horizon, even heuristically".. Back in the "good old days" I can't tell you how many times I saw that kind of nonsense. One in the early 70's where program A captured a rook on (I believe) h8 and thought it had outright won the rook with those shallow searches, but A then saw that the knight was going to be lost (it would still have had a winning position however). And it offered up a steady stream of pawn sacs to push the knight loss over the horizon. When all was said and done, A lost badly because it STILL lost the knight after giving away 3 or 4 pawns...

That was one of the things the "check extension" was created to address, so that spite checks didn't burn two plies at a time. About the only thing I have noticed recently is that while the horizon effect will be there until we can search to the end of the game, it is not nearly as noticeable today as it was 20-30 years ago.
User avatar
hgm
Posts: 27788
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Spite checks

Post by hgm »

Indeed, large depth seems to cure many things. But in games with piece drops there is usually a huge branching factor, which makes it quite difficult to reach high depth.

I wondered if it has ever been tried to simply prune all unsafe checks (with SEE < 0) in the last ply before QS.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Spite checks

Post by bob »

hgm wrote:Indeed, large depth seems to cure many things. But in games with piece drops there is usually a huge branching factor, which makes it quite difficult to reach high depth.

I wondered if it has ever been tried to simply prune all unsafe checks (with SEE < 0) in the last ply before QS.
I do this myself. If a check is unsafe according to see, it is never extended. If it is not extended, it can be reduced or pruned...