Answers.Body: <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-11-08T01:09:38.213Z
Answers.LastActivityDate: 2021-11-08T01:09:38.213Z
Answers.UserDisplayName: Michel Mainville
Answers.Body: <p>SF doesn't find mates. When it announces +Mn it's generally lying.
  See the examples in Arena <a href="https://www.chess.com/forum/view/more-puzzles/mates-that-are-difficult-for-engines?page=18#comment-99354381" rel="nofollow noreferrer">here</a> and <a href="https://www.chess.com/forum/view/more-puzzles/mates-that-are-difficult-for-engines?page=18#comment-99379391" rel="nofollow noreferrer">here</a>.</p>
  <p>See also comments following @user21820's post.</p>
  <p>The thread title should really be, &quot;Why does it take stockfish depth 35 to <em>announce</em> mate in 7?&quot;.
  But if it announces mate in 7 you <em><strong>cannot</strong></em> then assume there is a mate in 7 unless you either find such a mate yourself or check <em>all</em> alternative lines from different moves for the losing side in the example SF provides. SF <em>hasn't</em> necessarily checked them.</p>
  <p>To be more precise SF returns info commands that may contain <strong>score ±M<em>n</em></strong> with &quot;lowerbound&quot; or &quot;upperbound keys and most GUIs present these in a way that users will generally take as mate announcements. So it's the GUIs that are lying, not strictly speaking SF. SF is effective at hiding exactly what the contents of the <strong>info</strong> commands are in readily available documentation. Appealing to the UCI specification gets you no further - the price of a new set of false teeth for the programmer's granny in American cents appears to be UCI compliant as a score, with or without the &quot;M&quot;. It's only necessary that if the price changes during an analysis another <strong>info</strong> command is returned.</p>
  <p><strong>Edit:</strong> Arena flags the lowerbound and upperbound lines with a &quot;+&quot; or &quot;-&quot; following the depths field. In the second link above there are  +Mn scores shown in Arena with n increasing with time and no &quot;+&quot; or &quot;-&quot; following the depths field, so it would seem SF does lie as well as the GUIs.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-03-03T17:22:54.743Z
Answers.Text: You should ask a new question about why this behavior occurs. In your link you disabled NNUE, but most of Stockfish's evaluation relies on that nowadays.
Answers.UserDisplayName: qwr
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-03-04T06:40:47.200Z
Answers.Text: But I've seen the same behaviour with NNUE enabled. It'm simply pointing out that the idea that SF finds mates is a misconception.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-03-04T12:16:32.487Z
Answers.Text: @qwr I believe the chess.com GUI doesn't disable NNUE and another user has also noted the same behaviour there. I'm not particularly interested in correcting this behaviour so I won't ask a new question. You may like to do so yourself, but Stack Exchange may not be the best place. I thought it best to post an answer pointing it out because  it means OP's question is misconceived - but it's a widespread misconception.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-13T18:41:31.233Z
Answers.LastActivityDate: 2024-03-02T02:39:42.860Z
Answers.LastEditDate: 2024-03-02T02:39:42.860Z
Answers.UserDisplayName: Martin Rattigan
Answers.Body: <p>StockFish at its core uses alpha-beta pruning, as explained in <a href="https://chess.stackexchange.com/a/29842/9192">this post</a>. 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 <strong>may not</strong> be correct unlike alpha-beta pruning, but will <strong>greatly increase</strong> the final depth that the search can reach. That final depth is what SF means by &quot;depth 35&quot;. 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.</p>
  <p>In particular, the default setting of SF is <strong>not</strong> to find the fastest checkmate sequences alone but to find the best move in general, because it is much more computationally expensive to <em>prove</em> 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 <strong>all</strong> the branches necessary to <em>prove</em> 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.</p>
  <p>That said, I don't know why you say it needed depth 35. <a href="https://lichess.org/analysis/4k2r/pp3p2/2p4p/5n2/1PB5/P5PP/5K2/2q5_w_-_-_0_1" rel="nofollow noreferrer">Lichess analysis</a> clearly shows that it already found the #7 in the default depth-20 search.</p>
  <p>[Edit: With the current Lichess interface it seems that the search is limited by &quot;search time&quot; 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.]</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-31T19:00:24.463Z
Answers.Text: 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.
Answers.UserDisplayName: Herman
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T13:49:01.347Z
Answers.Text: 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.)
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T14:01:22.383Z
Answers.Text: @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!
Answers.UserDisplayName: user21820
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T14:35:17.137Z
Answers.Text: @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.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T14:44:50.087Z
Answers.Text: @MartinRattigan: I have seen many incidents of #k → no # that have other sufficient explanations. For example, if the cache is reset or the heuristics result in a different search tree, it may be that it can no longer prove checkmate despite having proven it earlier. Of course, I await any example, and I believe the authors of SF would want to see your examples too! =)
Answers.UserDisplayName: user21820
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T15:00:51.433Z
Answers.Text: @user21820 I'll look for one that came up in the chess.com forum. It happens pretty rarely so you'd have to very patient  if I just waited for one to turn up. It's also possible that it could take some reproducing even for positions where it has occurred.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T15:16:41.890Z
Answers.Text: @user21820 In the meantime I retract the bit about declaring mate in positions where it couldn't possibly have fully considered a complete half tree. I based it on just on the mate depth, but on consideration, I've seen it only in positions where there would be massive convergence of the mating lines.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T15:57:30.237Z
Answers.Text: @user21820 Didn't find the chess.com posts, but reproduced it for this position in Tarrasch with kibbitzer running. SF15.1+NNUE, 3GB hash, Intel(R) Pentium(R) CPU  J3710  @ 1.60GHz   1.60 GHz. Declared #34 then changed it's mind to an evaluation of 1.10 a couple of seconds later. Probably hard to reproduce but keep giving it mates in 40 in the same endgame and you'll probably see it.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T16:03:00.793Z
Answers.Text: @user21820 Forgot to post the position: 8/8/8/8/8/1NK4p/7N/3k4 b - - 11 6
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T16:09:40.160Z
Answers.Text: @user21820b Seen the same thing in Arena/SF, so I think the bug must be in SF.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-13T13:02:48.937Z
Answers.Text: @MartinRattigan: Thank you very much for that, but I am unable to reproduce it on Lichess. It may be because I cannot use NNUE. Can you turn NNUE off and check whether it still occurs?
Answers.UserDisplayName: user21820
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-13T17:37:01.807Z
Answers.Text: Actually, I think I was lying when I said it happens rarely. Here's an example in Arena - https://www.chess.com/forum/view/more-puzzles/mates-that-are-difficult-for-engines?page=18#comment-99354381
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-14T16:11:24.393Z
Answers.Text: @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!
Answers.UserDisplayName: user21820
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-16T15:58:24.933Z
Answers.Text: @user21820 If it announces mate it n it *has* concluded something false. There is no final conclusion. You can leave it kibbitzing for as long as you want. In most positions it will not complete a search in your lifetime. If it announces +M42 then changes its mind to +10.74 three minutes later as it does in the one of the examples I posted below, no doubt but it was lying with its +M42.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-16T16:31:31.957Z
Answers.Text: @user21820 As for your earlier comment regarding tablebases they currently run to only seven men. The examples I gave are without tablebase access. I think SF only uses Syzygy in which case they don't give a definite depth to mate. Mates found using Syzygy optimal moves for *both* sides can be shorter that the real mate depth.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-16T16:51:42.900Z
Answers.Text: As an example of my last sentence, if you download a sample game from 8/8/5N2/p7/8/k1K5/8/1N6 b - - 0 1 from the https://syzygy-tables.info/?fen=8/8/5N2/p7/8/k1K5/8/1N6_b_-_-_0_1 it gives you a mate in 51. But the position is actually mate in 85 without the 50 move rule or mate in 108 with the 50 move rule.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-17T03:48:46.367Z
Answers.Text: @MartinRattigan: No. You are not reading what I wrote; please read again what I said starting from "If it is halfway ...". If you still do not understand what I mean, it would be better for you to clarify than to assume. If you don't fix the search depth then you are **not** using SF in the manner that I have been talking about.
Answers.UserDisplayName: user21820
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-18T11:37:52.933Z
Answers.Text: I read everything you wrote. Up to my last comment you made no mention of specifying a fixed search depth. The UCI default is to leave the computation running until the GUI sends a **stop** command (you unclick the analysis button) or the engine decides to stop calculating, presumably because it decides its analysis is complete (which in most cases won't happen in any usable time). I've never used SCIDvsPC but I'd guess OP is using the default mode. The GUI can also add parameters to the **go** command to limit the analysis to a fixed depth or ... (continued)
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-18T12:04:34.160Z
Answers.Text: ... terminate the analysis after a fixed number of nodes or milliseconds or either. The GUI can determine that the analysis is finished when it receives a **bestmove**, but that is not an evaluation, just a move. The "final" evaluation is just the evaluation on the last **info** command received from the engine. If the **go** command in the first   example in my following post had included **nodes 883902000** the final evaluation could have been +M42 (I say could because the analyses are not exactly reproducible). ... (continued)
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-18T12:10:17.107Z
Answers.Text: ... That would be lying because if it had continued for another three minutes it would probably be displaying +10.74 instead. The statement in your post, "Whenever SF says #k, it means it searched all the branches necessary to prove that a checkmate can be guaranteed in ≤k moves.", is just not true for Stockfish. (I don't think many people would prefer it to lie to stop them getting bored either.)
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-19T06:05:10.253Z
Answers.Text: @MartinRattigan: Well ok. I made my statement based on the SF analysis on Lichess, which at least for many people runs a fixed-depth search, not an infinite one unless you ask for it, and not after a fixed number of nodes or milliseconds. I will edit my post to clarify that. (As for your parenthetical remark, I think you're wrong because SF can use multiple cores, in which case it may never have a full tree in infinite analysis, and so can only provide estimates based on the always partial tree. Even on 1 core, there may be asynchronous parallelism too.)
Answers.UserDisplayName: user21820
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-22T10:54:35.753Z
Answers.Text: The situation is similar on chess.com, but there are several salient points to make. The first is that OP is using Scid vs. PC so what SF options and **go** command are used in OP's case are the relevant ones. The second is if you use a fixed depth search how do you decide what depth to use if you don't already know the mate depth. ... (continued)
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-22T10:54:49.263Z
Answers.Text: ... The third is that SF will not necessarily find a mate even if it's within the fixed depth. The fourth is that chess.com doesn't appear to tell you when a search is complete whatever you use (haven't managed to fathom the mysteries of Lichess analysis yet so I don't know about that). The fifth is if you're looking for a mate in say 40 you can just look and look before the search does complete by finding it whatever options you use.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-22T11:43:29.227Z
Answers.Text: I have a bad habit of using too many parenthetical remarks. I think you must be referring to, "  (I say could because the analyses are not exactly reproducible)". That was meant to refer to the results terminated by *time* in some way and appears to agree with what you say. I think otherwise the results are reproducible if a single thread is used but not if multiple threads are in use (at least on a multicore system).
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-22T12:10:02.610Z
Answers.Text: I can post some examples supporting what I said in the previous comment if you like. Probably better in a private conversation because they would take some space. The main thrust of my post below is that you cannot rely on SF (at least not recent versions) to find mates because it lies when it announces mates and I think that applies to all cases - certainly to practical cases.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-22T12:32:59.393Z
Answers.Text: Slight clarification to my third previous post. If you give it a mate in 40 it will probably finish in practicable time (if you're very patient) if you use either **go** or **go infinite**.  But it's unlikely to finish with a mate announcement. Trying again will defiinitely not get you any further if you use a single thread and is unlikely if you use multiple. You assume that if it terminates with a mate announcement that it's checked a complete half tree to the mate, but I see no indication that is the case. It doesn't up to that point. ... (continued)
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-22T12:34:59.957Z
Answers.Text: ... If it always terminated with a mate announcement when there is such a mate your assumpttion would be plausible, but it doesn't. It can happily terminate without a mate prediction in situations where there is a mate, even a mate within the depth if **go depth n** is used.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-25T10:05:01.753Z
Answers.Text: I honestly want to know if there is a counter-example to what I stated (in my edited post), and want to engage with your comments too, but I'm kind of busy and don't have the energy right now.. It would be best if you can explicitly provide a position for which a fixed-depth Lichess analysis search generates a false checkmate claim, and then we can archive a screenshot of that for future readers. =)
Answers.UserDisplayName: user21820
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-25T11:25:46.213Z
Answers.Text: I will try. Can you give me a clue how to use it? I go into TOOLS>Analysis board and post a FEN but nothing happens except "no game found" or a set of stats from something called "Masters database" or if it's less than 7 men a reproduction of the syzygy-tables.info analysis.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-25T13:36:27.013Z
Answers.Text: For example, if you paste the FEN "8/8/5N2/p7/8/k1K5/8/1N6 b - - 0 1" into the FEN textbox and press Enter then it loads the position. After that, click the slider button at the top-left of the control panel next to the "Stockfish" title. It then starts running in your browser. However, I just noticed that with the updated interface it has a slider for "Search time", instead of depth as seems to have been the case in previous versions of Lichess that I had been playing with some time ago. I guess I may have to take back what I said about Lichess.
Answers.UserDisplayName: user21820
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-27T11:08:37.313Z
Answers.Text: "That said, I don't know why you say it needed depth 35" - that may be a difference between SF 6 (which OP is apparently using) and SF16, which I think Lichess is using.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-28T19:16:50.957Z
Answers.Text: @user21820 Thanks for the info on using Lichess analysis.
Answers.UserDisplayName: Martin Rattigan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-11-08T06:52:36.237Z
Answers.LastActivityDate: 2024-02-25T13:40:57.033Z
Answers.LastEditDate: 2024-02-25T13:40:57.033Z
Answers.UserDisplayName: user21820
Body: <p>My underlying question here is: <strong>What is depth?</strong></p>
  <p>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:</p>
  <ol>
  <li>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.</li>
  <li>But, now it finds M13, or mate in 25/26 ply, at depth 21, where it should be at at least depth 25. How?</li>
  <li>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?</li>
  </ol>
  <p><a href="https://i.sstatic.net/TckXl.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/TckXl.png" alt="enter image description here" /></a></p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-11-07T11:27:58.630Z
Comments.Text: Please could you add the FEN of the position in plain text?
Comments.UserDisplayName: Rosie F
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-11-07T22:42:50.557Z
Comments.Text: 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.
Comments.UserDisplayName: Scounged
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-11-08T21:07:17.930Z
Comments.Text: The short answer is that depth is an implementation detail
Comments.UserDisplayName: Sopel
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-02-18T18:02:47.277Z
Comments.Text: 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#
Comments.UserDisplayName: Martin Rattigan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-02-18T18:07:12.223Z
Comments.Text: Hash size makes a lot of difference. Mine is set to 3GB.
Comments.UserDisplayName: Martin Rattigan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-02-18T18:11:28.553Z
Comments.Text: @Rosie F Fen is 5q2/2K5/PP5P/2n2BP1/8/p4p2/2p3pp/r2k4 w - - 0 1
Comments.UserDisplayName: Martin Rattigan
Tags: <stockfish><depth>
Title: Why does it take stockfish depth 35 to find mate in 7?
ThreadText: # Why does it take stockfish depth 35 to find mate in 7?
  
  (Asked by: username_0 on 2021-11-07)
  
  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?
  
  [![enter image description here](https://i.sstatic.net/TckXl.png)](https://i.sstatic.net/TckXl.png)
  
  **Tags:** stockfish, depth
  
  > **Comments:**
  > **username_1**: Please could you add the FEN of the position in plain text?  
  > **username_2**: 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.  
  > **username_3**: The short answer is that depth is an implementation detail  
  > **username_4**: 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#  
  > **username_4**: Hash size makes a lot of difference. Mine is set to 3GB.  
  > **username_4**: @username_1 Fen is 5q2/2K5/PP5P/2n2BP1/8/p4p2/2p3pp/r2k4 w - - 0 1  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_7 on 2021-11-08. Score: 13 | Accepted answer
  
  StockFish at its core uses alpha-beta pruning, as explained in [this post](https://chess.stackexchange.com/a/29842/9192). 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](https://lichess.org/analysis/4k2r/pp3p2/2p4p/5n2/1PB5/P5PP/5K2/2q5_w_-_-_0_1) 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.]
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_4**: 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.)  
  > **username_7**: @username_4: 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!  
  > **username_4**: @username_7 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.  
  > **username_7**: @username_4: I have seen many incidents of #k → no # that have other sufficient explanations. For example, if the cache is reset or the heuristics result in a different search tree, it may be that it can no longer prove checkmate despite having proven it earlier. Of course, I await any example, and I believe the authors of SF would want to see your examples too! =)  
  > **username_4**: @username_7 I'll look for one that came up in the chess.com forum. It happens pretty rarely so you'd have to very patient  if I just waited for one to turn up. It's also possible that it could take some reproducing even for positions where it has occurred.  
  > **username_4**: @username_7 In the meantime I retract the bit about declaring mate in positions where it couldn't possibly have fully considered a complete half tree. I based it on just on the mate depth, but on consideration, I've seen it only in positions where there would be massive convergence of the mating lines.  
  > **username_4**: @username_7 Didn't find the chess.com posts, but reproduced it for this position in Tarrasch with kibbitzer running. SF15.1+NNUE, 3GB hash, Intel(R) Pentium(R) CPU  J3710  @ 1.60GHz   1.60 GHz. Declared #34 then changed it's mind to an evaluation of 1.10 a couple of seconds later. Probably hard to reproduce but keep giving it mates in 40 in the same endgame and you'll probably see it.  
  > **username_4**: @username_7 Forgot to post the position: 8/8/8/8/8/1NK4p/7N/3k4 b - - 11 6  
  > **username_4**: @user21820b Seen the same thing in Arena/SF, so I think the bug must be in SF.  
  > **username_7**: @username_4: Thank you very much for that, but I am unable to reproduce it on Lichess. It may be because I cannot use NNUE. Can you turn NNUE off and check whether it still occurs?  
  > **username_4**: Actually, I think I was lying when I said it happens rarely. Here's an example in Arena - https://www.chess.com/forum/view/more-puzzles/mates-that-are-difficult-for-engines?page=18#comment-99354381  
  > **username_7**: @username_4: 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!  
  > **username_4**: @username_7 If it announces mate it n it *has* concluded something false. There is no final conclusion. You can leave it kibbitzing for as long as you want. In most positions it will not complete a search in your lifetime. If it announces +M42 then changes its mind to +10.74 three minutes later as it does in the one of the examples I posted below, no doubt but it was lying with its +M42.  
  > **username_4**: @username_7 As for your earlier comment regarding tablebases they currently run to only seven men. The examples I gave are without tablebase access. I think SF only uses Syzygy in which case they don't give a definite depth to mate. Mates found using Syzygy optimal moves for *both* sides can be shorter that the real mate depth.  
  > **username_4**: As an example of my last sentence, if you download a sample game from 8/8/5N2/p7/8/k1K5/8/1N6 b - - 0 1 from the https://syzygy-tables.info/?fen=8/8/5N2/p7/8/k1K5/8/1N6_b_-_-_0_1 it gives you a mate in 51. But the position is actually mate in 85 without the 50 move rule or mate in 108 with the 50 move rule.  
  > **username_7**: @username_4: No. You are not reading what I wrote; please read again what I said starting from "If it is halfway ...". If you still do not understand what I mean, it would be better for you to clarify than to assume. If you don't fix the search depth then you are **not** using SF in the manner that I have been talking about.  
  > **username_4**: I read everything you wrote. Up to my last comment you made no mention of specifying a fixed search depth. The UCI default is to leave the computation running until the GUI sends a **stop** command (you unclick the analysis button) or the engine decides to stop calculating, presumably because it decides its analysis is complete (which in most cases won't happen in any usable time). I've never used SCIDvsPC but I'd guess OP is using the default mode. The GUI can also add parameters to the **go** command to limit the analysis to a fixed depth or ... (continued)  
  > **username_4**: ... terminate the analysis after a fixed number of nodes or milliseconds or either. The GUI can determine that the analysis is finished when it receives a **bestmove**, but that is not an evaluation, just a move. The "final" evaluation is just the evaluation on the last **info** command received from the engine. If the **go** command in the first   example in my following post had included **nodes 883902000** the final evaluation could have been +M42 (I say could because the analyses are not exactly reproducible). ... (continued)  
  > **username_4**: ... That would be lying because if it had continued for another three minutes it would probably be displaying +10.74 instead. The statement in your post, "Whenever SF says #k, it means it searched all the branches necessary to prove that a checkmate can be guaranteed in ≤k moves.", is just not true for Stockfish. (I don't think many people would prefer it to lie to stop them getting bored either.)  
  > **username_7**: @username_4: Well ok. I made my statement based on the SF analysis on Lichess, which at least for many people runs a fixed-depth search, not an infinite one unless you ask for it, and not after a fixed number of nodes or milliseconds. I will edit my post to clarify that. (As for your parenthetical remark, I think you're wrong because SF can use multiple cores, in which case it may never have a full tree in infinite analysis, and so can only provide estimates based on the always partial tree. Even on 1 core, there may be asynchronous parallelism too.)  
  > **username_4**: The situation is similar on chess.com, but there are several salient points to make. The first is that OP is using Scid vs. PC so what SF options and **go** command are used in OP's case are the relevant ones. The second is if you use a fixed depth search how do you decide what depth to use if you don't already know the mate depth. ... (continued)  
  > **username_4**: ... The third is that SF will not necessarily find a mate even if it's within the fixed depth. The fourth is that chess.com doesn't appear to tell you when a search is complete whatever you use (haven't managed to fathom the mysteries of Lichess analysis yet so I don't know about that). The fifth is if you're looking for a mate in say 40 you can just look and look before the search does complete by finding it whatever options you use.  
  > **username_4**: I have a bad habit of using too many parenthetical remarks. I think you must be referring to, "  (I say could because the analyses are not exactly reproducible)". That was meant to refer to the results terminated by *time* in some way and appears to agree with what you say. I think otherwise the results are reproducible if a single thread is used but not if multiple threads are in use (at least on a multicore system).  
  > **username_4**: I can post some examples supporting what I said in the previous comment if you like. Probably better in a private conversation because they would take some space. The main thrust of my post below is that you cannot rely on SF (at least not recent versions) to find mates because it lies when it announces mates and I think that applies to all cases - certainly to practical cases.  
  > **username_4**: Slight clarification to my third previous post. If you give it a mate in 40 it will probably finish in practicable time (if you're very patient) if you use either **go** or **go infinite**.  But it's unlikely to finish with a mate announcement. Trying again will defiinitely not get you any further if you use a single thread and is unlikely if you use multiple. You assume that if it terminates with a mate announcement that it's checked a complete half tree to the mate, but I see no indication that is the case. It doesn't up to that point. ... (continued)  
  > **username_4**: ... If it always terminated with a mate announcement when there is such a mate your assumpttion would be plausible, but it doesn't. It can happily terminate without a mate prediction in situations where there is a mate, even a mate within the depth if **go depth n** is used.  
  > **username_7**: I honestly want to know if there is a counter-example to what I stated (in my edited post), and want to engage with your comments too, but I'm kind of busy and don't have the energy right now.. It would be best if you can explicitly provide a position for which a fixed-depth Lichess analysis search generates a false checkmate claim, and then we can archive a screenshot of that for future readers. =)  
  > **username_4**: I will try. Can you give me a clue how to use it? I go into TOOLS>Analysis board and post a FEN but nothing happens except "no game found" or a set of stats from something called "Masters database" or if it's less than 7 men a reproduction of the syzygy-tables.info analysis.  
  > **username_7**: For example, if you paste the FEN "8/8/5N2/p7/8/k1K5/8/1N6 b - - 0 1" into the FEN textbox and press Enter then it loads the position. After that, click the slider button at the top-left of the control panel next to the "Stockfish" title. It then starts running in your browser. However, I just noticed that with the updated interface it has a slider for "Search time", instead of depth as seems to have been the case in previous versions of Lichess that I had been playing with some time ago. I guess I may have to take back what I said about Lichess.  
  > **username_4**: "That said, I don't know why you say it needed depth 35" - that may be a difference between SF 6 (which OP is apparently using) and SF16, which I think Lichess is using.  
  > **username_4**: @username_7 Thanks for the info on using Lichess analysis.  
  
  ---
  
  ### Answer by username_5 on 2021-11-08. Score: 2
  
  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.
  
  
  ---
  
  ### Answer by username_4 on 2024-02-13. Score: -1
  
  SF doesn't find mates. When it announces +Mn it's generally lying.
  See the examples in Arena [here](https://www.chess.com/forum/view/more-puzzles/mates-that-are-difficult-for-engines?page=18#comment-99354381) and [here](https://www.chess.com/forum/view/more-puzzles/mates-that-are-difficult-for-engines?page=18#comment-99379391).
  
  See also comments following @username_7's post.
  
  The thread title should really be, "Why does it take stockfish depth 35 to *announce* mate in 7?".
  But if it announces mate in 7 you ***cannot*** then assume there is a mate in 7 unless you either find such a mate yourself or check *all* alternative lines from different moves for the losing side in the example SF provides. SF *hasn't* necessarily checked them.
  
  To be more precise SF returns info commands that may contain **score ±M*n*** with "lowerbound" or "upperbound keys and most GUIs present these in a way that users will generally take as mate announcements. So it's the GUIs that are lying, not strictly speaking SF. SF is effective at hiding exactly what the contents of the **info** commands are in readily available documentation. Appealing to the UCI specification gets you no further - the price of a new set of false teeth for the programmer's granny in American cents appears to be UCI compliant as a score, with or without the "M". It's only necessary that if the price changes during an analysis another **info** command is returned.
  
  **Edit:** Arena flags the lowerbound and upperbound lines with a "+" or "-" following the depths field. In the second link above there are +Mn scores shown in Arena with n increasing with time and no "+" or "-" following the depths field, so it would seem SF does lie as well as the GUIs.
  
  > **Comments:**
  > **username_6**: You should ask a new question about why this behavior occurs. In your link you disabled NNUE, but most of Stockfish's evaluation relies on that nowadays.  
  > **username_4**: But I've seen the same behaviour with NNUE enabled. It'm simply pointing out that the idea that SF finds mates is a misconception.  
  > **username_4**: @username_6 I believe the chess.com GUI doesn't disable NNUE and another user has also noted the same behaviour there. I'm not particularly interested in correcting this behaviour so I won't ask a new question. You may like to do so yourself, but Stack Exchange may not be the best place. I thought it best to post an answer pointing it out because  it means OP's question is misconceived - but it's a widespread misconception.  
  
  ---
  
  