Early search termination

[sje]

Early search termination

Symbolic can terminate a search for several different reasons. Two of them, designed to save time that's better spent on a new game:

1) If the result of TWO consecutive iterations is a MateInN with N being the same for both results, then the search ends regardless of the amount of remaining time.

2) If the result of FOUR consecutive iterations is a LoseInN with N being the same for all four results, then the search ends regardless of the amount of remaining time.

Neither of the above implies an immediate end to the game. Rather, the idea is to shorten the remaining time spent on the game when the ultimate result is not in doubt.

Opinions?

[Ferdy]

Early search termination

Symbolic can terminate a search for several different reasons. Two of them, designed to save time that's better spent on a new game:

1) If the result of TWO consecutive iterations is a MateInN with N being the same for both results, then the search ends regardless of the amount of remaining time.

2) If the result of FOUR consecutive iterations is a LoseInN with N being the same for all four results, then the search ends regardless of the amount of remaining time.

Neither of the above implies an immediate end to the game. Rather, the idea is to shorten the remaining time spent on the game when the ultimate result is not in doubt.

Opinions?

Create options to enable, disable these things so that when you test mating abilities of your engine or opponent's engine you can just disable it.

[mvk]

Coincidently, in the upcoming 0.7 version of Floyd I also added a heuristic to recognise when the shortest mate has been found and then stop the search early [git commit here]. I stumbled upon this two weeks ago while fiddling with mate distance pruning and trying to find a technique to avoid flying through all the iterations in these scenarios, because XBoard temporarily freezes when that happens and that is annoying when you're trying to checkmate Spartacus with HGM sitting across.

In stripped down form it looks like this:

In rootSearch:

Code: Select all

                 for (int iteration=0; iteration<=depth; iteration++) {
                         self->mateStop = true;
                         self->score = pvSearch(self, iteration, -maxInt, maxInt, 0);
                         if (isMateScore(self->score) && self->mateStop && iteration > 0)
                             break; // <-- shortest mate heuristic
                 }

(Here, isMateScore() evaluates as true for both losing mate scores and winning mate scores.)

In pvSearch, after getting a score from scout:

Code: Select all

                 int score = -scout(self, newDepth, -(newAlpha+1), 1);
                 if (!isMateScore(score) && !isDrawScore(score))
                         self->mateStop = false; // shortest mate not yet proven

In scout just the regular mate distance pruning (I check for just one bound):

Code: Select all

         // Mate distance pruning
         int mateBound = maxMate - ply(self) - 2;
         if (mateBound <= alpha) return mateBound;

I must sheepishly confess that I don't yet fully grasp how it works(...), or more precisely, why on very rare occasions it stops a bit too soon. It is clear to me it operates as an interaction between PVS, fail-soft and mate distance pruning. It has a surprisingly effective correctness rate of about 99.5%. The program has null move and reductions BTW.

I have a gut feeling there is an exact algorithm hiding behind this heuristic waiting to be discovered resolving the remaining 0.5% of the cases. In the meantime I call it a "heuristic" and added it to Floyd for the practical advantages. I doubt that this is a new find, it is too simple for that.

[bob]

Coincidently, in the upcoming 0.7 version of Floyd I also added a heuristic to recognise when the shortest mate has been found and then stop the search early [git commit here]. I stumbled upon this two weeks ago while fiddling with mate distance pruning and trying to find a technique to avoid flying through all the iterations in these scenarios, because XBoard temporarily freezes when that happens and that is annoying when you're trying to checkmate Spartacus with HGM sitting across.

In stripped down form it looks like this:

In rootSearch:

Code: Select all

                 for (int iteration=0; iteration<=depth; iteration++) {
                         self->mateStop = true;
                         self->score = pvSearch(self, iteration, -maxInt, maxInt, 0);
                         if (isMateScore(self->score) && self->mateStop && iteration > 0)
                             break; // <-- shortest mate heuristic
                 }

(Here, isMateScore() evaluates as true for both losing mate scores and winning mate scores.)

In pvSearch, after getting a score from scout:

Code: Select all

                 int score = -scout(self, newDepth, -(newAlpha+1), 1);
                 if (!isMateScore(score) && !isDrawScore(score))
                         self->mateStop = false; // shortest mate not yet proven

In scout just the regular mate distance pruning (I check for just one bound):

Code: Select all

         // Mate distance pruning
         int mateBound = maxMate - ply(self) - 2;
         if (mateBound <= alpha) return mateBound;

I must sheepishly confess that I don't yet fully grasp how it works(...), or more precisely, why on very rare occasions it stops a bit too soon. It is clear to me it operates as an interaction between PVS, fail-soft and mate distance pruning. It has a surprisingly effective correctness rate of about 99.5%. The program has null move and reductions BTW.

I have a gut feeling there is an exact algorithm hiding behind this heuristic waiting to be discovered resolving the remaining 0.5% of the cases. In the meantime I call it a "heuristic" and added it to Floyd for the practical advantages. I doubt that this is a new find, it is too simple for that.

The problem I have had for years with this is LMR. Used to be able to stop if the score was mate in 7 and iteration depth >= 13. But no longer.

I still have a method based on the above, but a bit more liberal due to LMR. But once I find a mate and play that move, the next search stops when I find a mate in N-1... Since that proves I am making progress.

[mvk]

This shortest mate heuristic works the same under LMR. However, both mate distance pruning and fail-soft are pre-requisites for it to work at all. It doesn't stop at the first mate found. In case of mate it normally continues and only stops once the mate sequence is believed to be the shortest (and without having to know the magnitude of reductions).

[bob]

This shortest mate heuristic works the same under LMR. However, both mate distance pruning and fail-soft are pre-requisites for it to work at all. It doesn't stop at the first mate found. In case of mate it normally continues and only stops once the mate sequence is believed to be the shortest (and without having to know the magnitude of reductions).

Doesn't for me. IE if there is a mate in 7, there is no guarantee that a 13 ply search will find it. The mate move is not ordered first most of the time, so it ends up farther down the list and it gets reduced. Which can hide the "shortest mate" move for many plies...

I will dig up a position that shows this. IE mate in N at depth 2N-1, but in reality there is a mate in N-t where t is > 0, but it doesn't find it even at 2N-1, where 2(N-t)-1 is even shallower...

More later when I have time to look through some logs...

BTW I do mate distance pruning for the zero elo it is worth...

Here's the first one I found:

was 263. This is a mate in 8, which ought to be found in 15 plies. Takes me this long:

19 3.55/10.00 ++ 1. Qg8+! (>+10.89)
19 3.55/10.00 Mat04 1. Qg8+ Kxg8 2. Ne7+ Kf8 3. N7g6+ hxg6
4. Nxg6#


depth=19. Way outside my 2N-1 don't do another iteration limit. If it had found another longer mate, say a mate in 6 at depth=11, it would have stopped, never finding this mate in 4.

[mvk]

I think you are talking about a different algorithm, not the one I posted (but in fact one similar to the one I replaced because it didn't work under LMR).

[mvk]

Here an example:

The old mechanism stops after 9 plies and the wrong move:

Code: Select all

position fen 8/3r3P/q1p5/2Q5/1KP5/3P3r/8/1kB5 b - -
go
info string targetTime 0.000 alarmTime 0.000
info time 0 depth 0 score cp 769 nodes 14 nps 233017 hashfull 0 pv b1c1
info time 0 depth 1 score cp 769 nodes 156 nps 339902 hashfull 0 pv b1c1
info time 2 depth 2 score cp 737 nodes 795 nps 384067 hashfull 0 pv d7b7 c5b5 b1c1
info time 5 depth 3 score cp 518 nodes 1863 nps 405269 hashfull 0 pv a6b7 c5b5 b1c1 h7h8q h3h8 b5b7 d7b7 b4c5
info time 7 depth 4 score cp 518 nodes 2952 nps 423766 hashfull 0 pv a6b7 c5b5 b1c1 h7h8q h3h8 b5b7 d7b7 b4c5
info time 26 depth 5 score cp 518 nodes 12754 nps 497657 hashfull 1 pv a6b7 c5b5 b1c1 h7h8q h3h8 b5b7 d7b7 b4c5
info time 145 depth 6 score cp 606 nodes 82398 nps 567248 hashfull 7 pv d7d3 c5c6 d3b3 b4c5 a6a7 c5d6 h3d3 d6e6 a7h7
info time 322 depth 7 score mate 6 nodes 189058 nps 587204 hashfull 19 pv d7b7 b4c3 a6a1 c3d2 b7b2 c1b2 a1b2 d2e1 h3h1 c5g1 h1g1
info time 367 depth 8 score mate 6 nodes 222423 nps 606256 hashfull 21 pv d7b7 b4c3 a6a1 c3d2 b7b2 c1b2 a1b2 d2e1 h3h1 c5g1 h1g1
info time 547 depth 9 score mate 6 nodes 356531 nps 651737 hashfull 32 pv d7b7 b4c3 a6a1 c3d2 b7b2 c1b2 a1b2 d2e1 h3h1 c5g1 h1g1
bestmove d7b7 ponder b4c3

The version with the shortest mate heuristic continues until depth 11 before it believes it is optimal:

Code: Select all

position fen 8/3r3P/q1p5/2Q5/1KP5/3P3r/8/1kB5 b - - 
go
info time 0 depth 0 score cp 821 nodes 14 nps 215883 hashfull 0 pv b1c1
info time 0 depth 1 score cp 835 nodes 191 nps 397180 hashfull 0 pv d7b7 b4c3 b1c1
info time 1 depth 2 score cp 835 nodes 296 nps 434096 hashfull 0 pv d7b7 b4c3 b1c1
info time 3 depth 3 score cp 818 nodes 1438 nps 480131 hashfull 0 pv d7b7 b4c3 a6a1 c3d2 a1a2 d2d1 h3d3 d1e1 b7h7
info time 4 depth 4 score cp 887 nodes 2273 nps 515779 hashfull 0 pv d7b7 b4c3 a6a1 c3d2 a1a2 d2c3 b7b3 c3d4 b1c1 c5c6 h3h7
info time 13 depth 5 score cp 889 nodes 6898 nps 543197 hashfull 1 pv d7b7 c5b6 b7b6 b4c5 b1c1 h7h8r h3h8
info time 32 depth 6 score cp 896 nodes 19630 nps 609156 hashfull 2 pv d7b7 b4c3 a6a1 c3d2 a1a2 d2c3 b7b3 c3d4 a2a1 d4e4 b1c1 c5c6 h3h7
info time 228 depth 7 score mate 6 nodes 135646 nps 595545 hashfull 12 pv d7b7 b4c3 a6a1 c3d2 b7b2 c1b2 a1b2 d2e1 h3h1 c5g1 h1g1
info time 1052 depth 8 score mate 6 nodes 658840 nps 626549 hashfull 48 pv d7b7 b4c3 a6a1 c3d2 b7b2 c1b2 a1b2 d2e1 h3h1 c5g1 h1g1
info time 3053 depth 9 score mate 5 nodes 1865365 nps 610944 hashfull 122 pv h3d3 c5c6 a6c6 c1e3 d7b7 e3b6 c6b6 b4a4 b7a7
info time 4153 depth 10 score mate 5 nodes 2793619 nps 672619 hashfull 146 pv h3d3 c5c6 a6c6 c1e3 d7b7 e3b6 c6b6 b4a4 b7a7
info time 4508 depth 11 score mate 5 nodes 3564081 nps 790529 hashfull 146 pv h3d3 c5c6 a6c6 c1e3 d7b7 e3b6 c6b6 b4a4 b7a7
bestmove h3d3 ponder c5c6

Again, it doesn't know about, let alone actively anticipate, the reductions that happen under the hood.

Back on topic: Steven's suggestion (to count streaks of unchanged mate scores) is certainly simpler to understand and might be just as efficient. Although it needs a longer streak than the proposed 2 for this position. I'm interested in the success rate on this file with selected dm -4 .. +5 positions: qmate.epd (derived from Dann's 1MMM).

[bob]

Here an example:

The old mechanism stops after 9 plies and the wrong move:

Code: Select all

position fen 8/3r3P/q1p5/2Q5/1KP5/3P3r/8/1kB5 b - -
go
info string targetTime 0.000 alarmTime 0.000
info time 0 depth 0 score cp 769 nodes 14 nps 233017 hashfull 0 pv b1c1
info time 0 depth 1 score cp 769 nodes 156 nps 339902 hashfull 0 pv b1c1
info time 2 depth 2 score cp 737 nodes 795 nps 384067 hashfull 0 pv d7b7 c5b5 b1c1
info time 5 depth 3 score cp 518 nodes 1863 nps 405269 hashfull 0 pv a6b7 c5b5 b1c1 h7h8q h3h8 b5b7 d7b7 b4c5
info time 7 depth 4 score cp 518 nodes 2952 nps 423766 hashfull 0 pv a6b7 c5b5 b1c1 h7h8q h3h8 b5b7 d7b7 b4c5
info time 26 depth 5 score cp 518 nodes 12754 nps 497657 hashfull 1 pv a6b7 c5b5 b1c1 h7h8q h3h8 b5b7 d7b7 b4c5
info time 145 depth 6 score cp 606 nodes 82398 nps 567248 hashfull 7 pv d7d3 c5c6 d3b3 b4c5 a6a7 c5d6 h3d3 d6e6 a7h7
info time 322 depth 7 score mate 6 nodes 189058 nps 587204 hashfull 19 pv d7b7 b4c3 a6a1 c3d2 b7b2 c1b2 a1b2 d2e1 h3h1 c5g1 h1g1
info time 367 depth 8 score mate 6 nodes 222423 nps 606256 hashfull 21 pv d7b7 b4c3 a6a1 c3d2 b7b2 c1b2 a1b2 d2e1 h3h1 c5g1 h1g1
info time 547 depth 9 score mate 6 nodes 356531 nps 651737 hashfull 32 pv d7b7 b4c3 a6a1 c3d2 b7b2 c1b2 a1b2 d2e1 h3h1 c5g1 h1g1
bestmove d7b7 ponder b4c3

The version with the shortest mate heuristic continues until depth 11 before it believes it is optimal:

Code: Select all

position fen 8/3r3P/q1p5/2Q5/1KP5/3P3r/8/1kB5 b - - 
go
info time 0 depth 0 score cp 821 nodes 14 nps 215883 hashfull 0 pv b1c1
info time 0 depth 1 score cp 835 nodes 191 nps 397180 hashfull 0 pv d7b7 b4c3 b1c1
info time 1 depth 2 score cp 835 nodes 296 nps 434096 hashfull 0 pv d7b7 b4c3 b1c1
info time 3 depth 3 score cp 818 nodes 1438 nps 480131 hashfull 0 pv d7b7 b4c3 a6a1 c3d2 a1a2 d2d1 h3d3 d1e1 b7h7
info time 4 depth 4 score cp 887 nodes 2273 nps 515779 hashfull 0 pv d7b7 b4c3 a6a1 c3d2 a1a2 d2c3 b7b3 c3d4 b1c1 c5c6 h3h7
info time 13 depth 5 score cp 889 nodes 6898 nps 543197 hashfull 1 pv d7b7 c5b6 b7b6 b4c5 b1c1 h7h8r h3h8
info time 32 depth 6 score cp 896 nodes 19630 nps 609156 hashfull 2 pv d7b7 b4c3 a6a1 c3d2 a1a2 d2c3 b7b3 c3d4 a2a1 d4e4 b1c1 c5c6 h3h7
info time 228 depth 7 score mate 6 nodes 135646 nps 595545 hashfull 12 pv d7b7 b4c3 a6a1 c3d2 b7b2 c1b2 a1b2 d2e1 h3h1 c5g1 h1g1
info time 1052 depth 8 score mate 6 nodes 658840 nps 626549 hashfull 48 pv d7b7 b4c3 a6a1 c3d2 b7b2 c1b2 a1b2 d2e1 h3h1 c5g1 h1g1
info time 3053 depth 9 score mate 5 nodes 1865365 nps 610944 hashfull 122 pv h3d3 c5c6 a6c6 c1e3 d7b7 e3b6 c6b6 b4a4 b7a7
info time 4153 depth 10 score mate 5 nodes 2793619 nps 672619 hashfull 146 pv h3d3 c5c6 a6c6 c1e3 d7b7 e3b6 c6b6 b4a4 b7a7
info time 4508 depth 11 score mate 5 nodes 3564081 nps 790529 hashfull 146 pv h3d3 c5c6 a6c6 c1e3 d7b7 e3b6 c6b6 b4a4 b7a7
bestmove h3d3 ponder c5c6

Again, it doesn't know about, let alone actively anticipate, the reductions that happen under the hood.

Back on topic: Steven's suggestion (to count streaks of unchanged mate scores) is certainly simpler to understand and might be just as efficient. Although it needs a longer streak than the proposed 2 for this position. I'm interested in the success rate on this file with selected dm -4 .. +5 positions: qmate.epd (derived from Dann's 1MMM).

It looks like it has the same effect as what I do. You stopped after 2*M-1 iterations for a mate in M. Here is what my older version would do:

Code: Select all

          8     0.03/16:39  -Mat06   1. ... Rhxd3 2. Qb5 cxb5 3. h8=Q Qa4+
                                     4. Kc5 Qxc4+ 5. Kb6 R3d6+ 6. Ka5 Ra7#
                                     (s=2)
          8->   0.03/16:39  -Mat06   1. ... Rhxd3 2. Qb5 cxb5 3. h8=Q Qa4+
                                     4. Kc5 Qxc4+ 5. Kb6 R3d6+ 6. Ka5 Ra7#
                                     (s=2)
          9     0.03/16:39  -Mat05   1. ... Rhxd3 2. Qb5 cxb5 3. h8=Q Rb3+
                                     4. Kxb3 Qa4+ 5. Kc3 Qxc4# (s=2)
          9->   0.04/16:39  -Mat05   1. ... Rhxd3 2. Qb5 cxb5 3. h8=Q Rb3+
                                     4. Kxb3 Qa4+ 5. Kc3 Qxc4# (s=2)

It didn't stop until depth 9 (Mat05 * 2 - 1 = 9 iterations). That one isn't a problem for me either. It is the ones where the shortest mate move appears much later in the move list and gets reduced. Good captures never do this...

One to try. WAC 96. I find that Qd8+ is a mate in 15 here:

Code: Select all

         17     0.01/24.30   Mat15   1. Qd8+ Qf8 2. Rxh6+ Bxh6 3. Qxf8+ Bxf8
                                     4. Rh1+ Bh3 5. Rxh3+ Bh6 6. Rxh6+ Kg7
                                     7. Rh7+ Kf8 8. Bxd5 Nd2+ 9. Kc1 Nb3+
                                     10. cxb3 Re8 11. Rf7+ Kg8 12. Rxc7+ Re6
                                     13. Bxe6+ Kf8 14. g7+ Ke8 15. g8=Q#

Depth 17 0.01 seconds

A little later:

Code: Select all

         19     0.05/19.20   Mat11   1. Qd8+ Qf8 2. Rxh6+ Bxh6 3. g7+ Kxg7
                                     4. Qf6+ Kh7 5. Qg6+ Kh8 6. Rh1 Nd2+ 7. Kc1
                                     Nb3+ 8. cxb3 Bh3 9. Rxh3 Qc5+ 10. dxc5 Rf8
                                     11. Rxh6#

depth 19, 0.05 seconds, mate in 11.

and finally this:

Code: Select all

         23     0.18/18.00   Mat09   1. Qd8+ Qf8 2. Rxh6+ Bxh6 3. Qf6+ Qg7
                                     4. Rh1 Bh3 5. Rxh3 Nd2+ 6. Kc1 Nb3+
                                     7. cxb3 Qxf6 8. exf6 Rb8 9. Rxh6#

Finally, depth=23, 0.18 seconds, mate in 9. Note that the mate in 11 would (in the past) have terminated at depth=21 (11 * 2 - 1 plies) which would not find it.

Does your fix catch that? That is but one example, however, I am still looking for the position I ran across a couple of weeks ago where the shorter mate was a different move completely, which greatly delayed finding it.

[mvk]

It didn't stop until depth 9 (Mat05 * 2 - 1 = 9 iterations).

Correct. So far I have not observed this heuristic stop before that 2*M-1 limit (which is comforting to observe, but one would hope for a 2*M-3(!) limit: after all, if I have just found a +M3 line in 3 ply search I might "know", in the absence of reductions, that looking for a +M2 line will be futile, but the heuristic doesn't catch this aspect.)

That one isn't a problem for me either. It is the ones where the shortest mate move appears much later in the move list and gets reduced. Good captures never do this...

One to try. WAC 96. I find that Qd8+ is a mate in 15 here:

Code: Select all

         17     0.01/24.30   Mat15   1. Qd8+ Qf8 2. Rxh6+ Bxh6 3. Qxf8+ Bxf8
                                     4. Rh1+ Bh3 5. Rxh3+ Bh6 6. Rxh6+ Kg7
                                     7. Rh7+ Kf8 8. Bxd5 Nd2+ 9. Kc1 Nb3+
                                     10. cxb3 Re8 11. Rf7+ Kg8 12. Rxc7+ Re6
                                     13. Bxe6+ Kf8 14. g7+ Ke8 15. g8=Q#

Depth 17 0.01 seconds

A little later:

Code: Select all

         19     0.05/19.20   Mat11   1. Qd8+ Qf8 2. Rxh6+ Bxh6 3. g7+ Kxg7
                                     4. Qf6+ Kh7 5. Qg6+ Kh8 6. Rh1 Nd2+ 7. Kc1
                                     Nb3+ 8. cxb3 Bh3 9. Rxh3 Qc5+ 10. dxc5 Rf8
                                     11. Rxh6#

depth 19, 0.05 seconds, mate in 11.

and finally this:

Code: Select all

         23     0.18/18.00   Mat09   1. Qd8+ Qf8 2. Rxh6+ Bxh6 3. Qf6+ Qg7
                                     4. Rh1 Bh3 5. Rxh3 Nd2+ 6. Kc1 Nb3+
                                     7. cxb3 Qxf6 8. exf6 Rb8 9. Rxh6#

Finally, depth=23, 0.18 seconds, mate in 9. Note that the mate in 11 would (in the past) have terminated at depth=21 (11 * 2 - 1 plies) which would not find it.

Does your fix catch that? That is but one example, however, I am still looking for the position I ran across a couple of weeks ago where the shorter mate was a different move completely, which greatly delayed finding it.

Yes, it fixes such cases. Or better is to say that it falls within the 99.5% of mate positions in which the heuristic works.

For this WAC #96 position, if you can excuse the search explosion that an engine at Floyd's level exhibits, (Rookie, for example, falls straight from heuristic eval to +M9 at 1.8 s in the d=11 iteration), Floyd finds it at iteration 14, so that doesn't prove of disprove anything.

Code: Select all

position fen r1b4k/ppp2Bb1/6Pp/3pP3/1qnP1p1Q/8/PPP3P1/1K1R3R w - -
go
info time 0 depth 0 score cp 6 nodes 8 nps 66709 hashfull 0
info time 1 depth 1 score cp 41 nodes 92 nps 166974 hashfull 0 pv h4d8 g7f8
info time 1 depth 2 score cp 133 nodes 284 nps 246724 hashfull 0 pv h4d8 b4f8 d8d5
info time 2 depth 3 score cp 119 nodes 482 nps 292485 hashfull 0 pv h4d8 b4f8 d8f8 g7f8 f7d5
info time 2 depth 4 score cp 89 nodes 822 nps 335773 hashfull 0 pv h4d8 b4f8 d8f8 g7f8 f7d5 c4e3
info time 4 depth 5 score cp 77 nodes 1640 nps 379722 hashfull 0 pv h4d8 b4f8 d8f8 g7f8 f7d5 c4e3 c2c4 e3d1 h1d1
info time 11 depth 6 score cp 52 nodes 4849 nps 459880 hashfull 1 pv h4d8 b4f8 d8f8 g7f8 f7d5 c4e3 d5f3 e3d1 h1d1
info time 21 depth 7 score cp 208 nodes 11207 nps 541115 hashfull 1 pv h4d8 b4f8 h1h6 g7h6 d8f8 h6f8 d1h1 f8h6 h1h6 h8g7 h6h7 g7f8 f7d5
info time 37 depth 8 score cp 184 nodes 21116 nps 568123 hashfull 2 pv h4d8 b4f8 h1h6 g7h6 d8f8 h6f8 d1h1 f8h6 h1h6 h8g7 h6h7 g7f8 f7d5 c4e3
info time 113 depth 9 score cp 193 nodes 62661 nps 554120 hashfull 5 pv h4d8 b4f8 h1h6 g7h6 d8f8 h6f8 d1h1 f8h6 h1h6 h8g7 h6h7 g7f8 f7d5 c4d2 b1c1 c7c6
info time 190 depth 10 score cp 523 nodes 111965 nps 588058 hashfull 8 pv h4d8 b4f8 h1h6 g7h6 d8f8 h6f8 d1h1 f8h6 h1h6 h8g7 h6h7 g7f8 f7d5 c4d2 b1c1 d2b3 d5b3 c7c6
info time 349 depth 11 score cp 524 nodes 218126 nps 625089 hashfull 14 pv h4d8 b4f8 h1h6 g7h6 d8f8 h6f8 d1h1 f8h6 h1h6 h8g7 h6h7 g7f8 f7d5 f8e8 d5f7 e8f8 f7c4 c7c6
info time 657 depth 12 score cp 522 nodes 443676 nps 675302 hashfull 26 pv h4d8 b4f8 h1h6 g7h6 d8f8 h6f8 d1h1 f8h6 h1h6 h8g7 h6h7 g7f8 f7d5 c4d2 b1c1 f8e8 c1d2 c7c6 h7h8 e8e7
info time 210480 depth 13 score mate 11 nodes 143206389 nps 680380 hashfull 1000 pv h4d8 b4f8 h1h6 g7h6 g6g7 h8g7 d8f6 g7h7 f6g6 h7h8 d1h1 c4d2 b1c1 d2b3 c2b3 c8h3 h1h3 c7c5 h3h6 f8h6 g6h6
info time 1055443 depth 14 score mate 9 nodes 699472496 nps 662729 hashfull 1000 pv h4d8 b4f8 h1h6 g7h6 d8f6 f8g7 d1h1 c4d2 b1c1 d2b3 c2b3 c8h3 h1h3 g7f6 e5f6 c7c6 h3h6
... etc ...

As an example to address your case I can offer the one below for consideration:

Code: Select all

position fen 8/8/8/Kn4q1/6p1/4kp2/8/1b6 b - -
go
info time 0 depth 0 score cp 825 nodes 1 nps 29537 hashfull 0
info time 0 depth 1 score cp 825 nodes 47 nps 292048 hashfull 0 pv g5h6
info time 0 depth 2 score cp 825 nodes 88 nps 411481 hashfull 0 pv g5h6 a5b4
info time 0 depth 3 score cp 825 nodes 175 nps 533821 hashfull 0 pv g5h6 a5b4 h6h8
info time 0 depth 4 score cp 825 nodes 262 nps 616671 hashfull 0 pv g5h6 a5b4 h6h8 b4c5
info time 1 depth 5 score cp 825 nodes 401 nps 665052 hashfull 0 pv g5h6 a5b4 h6h8 b4c5 h8h7
info time 2 depth 6 score cp 1060 nodes 1137 nps 745144 hashfull 0 pv f3f2 a5b6 f2f1q b6c6 g5h6 c6d7 h6h8
info time 5 depth 7 score cp 1060 nodes 4992 nps 948707 hashfull 0 pv f3f2 a5b6 f2f1q b6c6 g5h6 c6d7 h6h8 d7e7
info time 32 depth 8 score cp 1060 nodes 33857 nps 1045034 hashfull 3 pv f3f2 a5b6 f2f1q b6c6 g5h6 c6d7 h6h8 d7e7 h8h7 e7e8
info time 208 depth 9 score mate 5 nodes 239199 nps 1151851 hashfull 15 pv b5a7 a5b6 g5d5 b6a7 d5c6 a7b8 c6b6 b8a8 b1e4
info time 315 depth 10 score mate 4 nodes 395476 nps 1255875 hashfull 20 pv g5c5 a5a6 b1d3 a6b7 d3e4 b7b8 c5f8
info time 330 depth 11 score mate 4 nodes 439281 nps 1332031 hashfull 20 pv g5c5 a5a6 b1d3 a6b7 d3e4 b7b8 c5f8
info time 345 depth 12 score mate 4 nodes 483126 nps 1399234 hashfull 20 pv g5c5 a5a6 b1d3 a6b7 d3e4 b7b8 c5f8
bestmove g5c5 ponder a5a6

A 2*M-1 criteria would not have found g5c5.

Making comparisons based on individual positions is not very helpful except to demonstrate a specific trait. Checkmate finding is never an elo-thing, and falling into the shortest line or making a detour first is often a matter of coincidence.