# Why continue to increase search depth after mate is found?

Playing with test sets, several times I come across a behavior of the chess engines which I can't understand: Let's say I have the endgame

``````[FEN "8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - 0 1"]
``````

which after an amazing 3 sec of analysis with asmFish9, I know it's at most a mate in 45 moves. The needed moves then continuously decrease until the result seems to stabilize to a mate in 32 moves (found already after 22 sec., with a 57-ply search). Now my question: since the engine knows the maximum number of moves needed for this position in order to force a mate is 32, why does this ply number continue to increase and increase if I let the engine search? As I write, after 27 min. of searching, the mate is still a mate in 32, but the ply depth has reached 100(!). Even if a ply was 1/2 move, I'd claim that the maximum ply depth to be searched would be 64 for a known mate in 32. What's going on here, why does the engine continue to go to depth? I'd find it more logical if it would just stop at 64 and rather search to the sides, in case a earlier mate exists.

When an engine searches, it doesn't look at all possible moves. It has to do Alpha-Beta pruning, where it rules out moves it considers extremely bad, and doesn't even consider them.

Once the engine finds a move, one of the things it does is then go back to these moves that are probably bad, and reconsiders them. I'm guessing that the 100 ply search depth is dedicated to those sidelines, with the engine trying to find a better line than the one it originally suggested.

You're right though that this would be impossible, given the engine already found a mate in 32, or 64 ply. But engines don't care how good their original line is, they always try to find a better one (what else would an engine do in the meantime?). Maybe it's more logical to get an engine to stop searching in the scenario you mentioned with the quickest possible checkmate, but again it's not like it has anything else to do.

When they perfect AGIs that can specialize in a variety of things at the same time, you'll probably see your logic implemented. But for now, mere AIs may as well search indefinitely.

• <go back to these moves that are probably bad, and reconsiders them> <engines don't care how good their original line is, they always try to find a better one> For example, a line which starts with a move which seemed on earlier analysis to be bad, but turned out after all to lead to a shorter mate? – Rosie F May 4 '18 at 4:59
• @Rosie F Yes, exactly. This is why engines occasionally change their evaluation of a position after thinking for a while. – Inertial Ignorance May 4 '18 at 22:35
• I'd just like to note that Alpha-Beta pruning actually only prunes lines that are guaranteed to be suboptimal. In fact, chess engines apply other methods of pruning and reductions such as null move pruning, futility pruning, and late move reductions that allow them to search more deeply at the risk of possibly ignoring optimal lines. – Stoud May 27 '18 at 3:36
• @Stoud A line is never guaranteed to be suboptimal though, since an engine could have misevaluated a line it deems suboptimal. For Example, if the engine evaluates MIN Node A to be +5 and evaluates one branch of MIN Node B to be +4, it will prune Node B. But it's possible the engine could have misevaluated that one branch of MIN Node B since it didn't look deep enough (which would mean it was wrong to prune Node B in the first place). – Inertial Ignorance May 27 '18 at 4:03
• @InertialIgnorance Yes, however my point is that searching the nodes pruned purely because of the alpha beta pruning is a complete waste of time, because they are guaranteed to have a worse evaluation. In most engines, this means that if only alpha beta pruning is used and a mate in 7 is found, there cannot be a more efficient mate that was pruned. – Stoud Jun 5 '18 at 5:01

I suspect it's an edge-case optimization that doesn't really matter.

What is the point in spending time making your engine more efficient at searching once mate has been found? You've already found mate! Your job here is done.

The performance cost of having some additional check of `if(currentPly > matePly){...}` called millions of times isn't worth the "benefit" of more efficient post-mate searches.