# Why does it take stockfish depth 35 to find mate in 7?

My underlying question here is: What is depth?

I know depth is supposedly the number of half-moves or plies from the starting position that it has calculated, in at least one line. But I feel this explanation is not congruent with the result you're seeing here:

1. I'd expect mate in 7 to be found at depth 14, but I understand it didn't search every line so okay it found it when it had already searched somewhere to depth 21. So far so good.
2. But, now it finds M13, or mate in 25/26 ply, at depth 21, where it should be at at least depth 25. How?
3. Furthermore, the depth keeps increasing after finding mate in 13 (ply 26). Why would it keep searching in sequences that are longer than the mate it already found? All subsequent analyses should stay below 26 ply right?

• Please could you add the FEN of the position in plain text? Nov 7, 2021 at 11:27
• The reason why the computer doesn't find the mate at depth 14 is because of pruning; it will not search all possible variatons 14 plies deep, but only look at the most "reasonable" ones according to its algorithm. As to why it finds the mate at depth 35 I guess it has to do with the computer increasing its depth by one step for each iteration of the algorithm, and it needs 35 such iterations before it actually finds the quickest mate. Since I'm no expert I'm waiting for someone who knows more about this to give a complete answer. Nov 7, 2021 at 22:42
• The short answer is that depth is an implementation detail Nov 8, 2021 at 21:07
• Incidentally my SF15.1+NNUE declares mate in 6 in a few seconds, depth circa 24. In this case I don't think it's lying, but it's human checkable. Line it gives is 1.Bxc2+ Kxc2 2.h7 h1=Q 3.b7 Rd1 4.Kc6 Qd6 5.Kb5 Rb1+ 6.Kc4 Qh4# Feb 18 at 18:02
• Hash size makes a lot of difference. Mine is set to 3GB. Feb 18 at 18:07

StockFish at its core uses alpha-beta pruning, as explained in this post. Alpha-beta pruning by itself always gives a correct move according to perfect play, assuming the final position evaluation heuristics are correct. However, SF uses not only alpha-beta pruning, but also many other pruning heuristics that may not be correct unlike alpha-beta pruning, but will greatly increase the final depth that the search can reach. That final depth is what SF means by "depth 35". It does not mean that SF searched every line to depth 35, because it would prune off the vast majority of lines. So if those pruning heuristics are incorrect, then SF may prune off the branch with the depth-7 forced checkmate sequence at lower final search depth.

In particular, the default setting of SF is not to find the fastest checkmate sequences alone but to find the best move in general, because it is much more computationally expensive to prove a checkmate sequence. Whenever SF says #k after a fixed-depth search (such as on Lichess analysis), as far as I can tell it does imply that it searched all the branches necessary to prove that a checkmate can be guaranteed in ≤k moves. But since SF is (wisely) designed not to search for the fastest checkmate sequence (which makes it much faster), it sometimes fails to see the optimal line because it had already checked other lines that looked more promising according to the sometimes incorrect heuristics, and those lines already yielded a successful forced checkmate.

That said, I don't know why you say it needed depth 35. Lichess analysis clearly shows that it already found the #7 in the default depth-20 search.

[Edit: With the current Lichess interface it seems that the search is limited by "search time" with default being 4 s, meaning that it is not fixed-depth. I still believe that fixed-depth SF search should yield correct conclusion for forced checkmate.]

• Aah, I hadn't considered the additional computation needed to prove something is a checkmate sequence. So the Bf1, Qb2+ sequence is very strong but it later proved that with Bb3, Nxh3+ mate was also inescapable and faster. My feeling remains that depth doesn't not mean what one would think it does. Oct 31, 2022 at 19:00
• Actually, when SF says #k, it may be just lying. It says it for depths it couldn't possibly have fully considered a complete half tree and sometimes changes its mind to #k+r or drops the mate announcement and gives a maximal score instead. (I'd count that as a bug.) Jan 12 at 13:49
• @MartinRattigan: Please show an example. I have never seen SF lie when it says #k, and I don't believe that it does. If it does, I would agree with you that it is a bug. Don't forget that SF has an endgame tablebase, so it can potentially find #k for rather large k! Jan 12 at 14:01
• @user21820 I haven't kept any examples, unfortunately, but I've seen it several times, as have others on the chess.com forum. I'll post an example when I next see one. My SFs don't have an EGT btw. I think they only take Syzygy, which wouldn't generally give you a distance to mate. Jan 12 at 14:35
• @MartinRattigan: That's not at all convincing. (1) As the last commenter said, you can only criticize the engine if it concludes something that is actually false. (2) The previous point applies only for the final conclusion, not any intermediate claims SF makes. The reason is that we cannot assume that its intermediate outputs actually mean anything at all. If it is halfway computing the search tree, it may conceivably show you the value of the partial tree even if it is possibly far from the value of the full tree. Why might it do that? Of course so that you don't complain that it lags! Feb 14 at 16:11

Because it is not thinking to depth 35 for all moves. These newer engines have multiple levels of thinking. When it says level 35, that means the level of deep thinking. It may only be thinking of 1 or 2 lines to ply 35. Then it works backwards in the tree to look for better moves at an earlier ply. Probably at depth 35 it found a theme which it could used earlier in the tree but had rejected at an earlier depth. Ultimately, when it says depth 35, it is really at that depth anyway. It uses 2 numbers like 24/35. That means that it is thinking of moves at ply 24 but it extends the lines of thinking to ply 35 to calculate the evaluation better. Still, it can only accept so many moves up to ply 24 in order to solve in a reasonable time so it has to sometimes backtrack later when it learns of a new move. For example, there could be a deflection involved. Deflections are not moves the engines normally consider. However, smart engines will discover the deflection later as it serves a purpose to prevent some later move from happening. It then works backwards to find the deflection. This is effectively how humans find deflections, also.

SF doesn't find mates. When it announces +Mn it's generally lying. See the examples in Arena here and here.