lichess.org
Donate

Stockfish flags as "Innacurate" the fastest checkmate sequence

You can see that the checkmate sequence with Kc5 is faster than the recommended e6 yet the engine marks the fastest mate as innacurate because of "Lost checkmate sequence".

In the analysis board it realizes it's a mate in #4 after Kc5. Which is a faster mate than e6!
@emaN-drawkcaB said in #1:
> You can see that the checkmate sequence with Kc5 is faster than the recommended e6 yet the engine marks the fastest mate as innacurate because of "Lost checkmate sequence".
>
> PPXAKE
> (2233)
> 00:41
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> a
> b
> c
> d
> e
> f
> g
> h
> emaN-drawkcaB
> (2102)
> 00:05
> 1.
> d4
> d6
> 2.
> c4
> e5
> A41 Rat Defense: English Rat
> 3.
> dxe5
> dxe5
> 4.
> Qc2
> ...
> (-0.05 -0.91) Inaccuracy. Qxd8+ was best.
> 4.Qxd8+Kxd85.Nc3Be66.b3Nd77.g3Bb48.Bb2a5
> 4.
> ...
> Be6
> 5.
> g3
> Bc5
> (-0.77 -0.06) Inaccuracy. Nc6 was best.
> 5...Nc6
> 6.
> Bg2
> c6
> 7.
> Nf3
> f6
> 8.
> O-O
> Nd7
> 9.
> a3
> a5
> 10.
> Nc3
> Qc7
> 11.
> Ne4
> Be7
> 12.
> Rd1
> b6
> 13.
> b3
> Nh6
> (1.30 2.37) Inaccuracy. Kf7 was best.
> 13...Kf714.h3
> 14.
> Bxh6
> gxh6
> 15.
> Nc3
> ...
> (2.61 0.93) Mistake. Qd2 was best.
> 15.Qd2O-O16.Qxh6Rad817.Bh3Bxh318.Qxh3Nc519.Nxc5Bxc520.Rxd8Rxd821.Qe6+Kg7
> 15.
> ...
> O-O
> 16.
> Qd2
> Rad8
> 17.
> Qxh6
> Nc5
> 18.
> Nd2
> ...
> (1.44 -0.08) Mistake. b4 was best.
> 18.b4
> 18.
> ...
> Rxd2
> 19.
> Rxd2
> Nxb3
> 20.
> Be4
> Rf7
> 21.
> Rad1
> Nxd2
> 22.
> Rxd2
> Bxc4
> 23.
> Bf5
> Bxa3
> 24.
> Ne4
> ...
> (-0.32 -1.11) Inaccuracy. Qh4 was best.
> 24.Qh4
> 24.
> ...
> Bc1
> (-1.11 5.25) Blunder. Kh8 was best.
> 24...Kh825.Rc2
> 25.
> Bxh7+
> Rxh7
> 26.
> Nxf6+
> Kf7
> 27.
> Qxh7+
> Kxf6
> 28.
> Qxc7
> Bxd2
> 29.
> Qxc6+
> Be6
> 30.
> Qxb6
> a4
> 31.
> Qd8+
> Kf7
> 32.
> Qxd2
> Bb3
> (5.36 7.07) Inaccuracy. a3 was best.
> 32...a333.Qa5a234.Qxe5Bc435.h4Kg836.h5Kh737.Kg2a1=Q38.Qc7+Kh639.Qxc4
> 33.
> f4
> Ke6
> 34.
> e4
> a3
> (6.73 15.75) Inaccuracy. exf4 was best.
> 34...exf435.Qd4fxg336.hxg3Ke737.Qb6Kf738.Kf2Kg739.g4Kf740.Ke3Ke741.g5
> 35.
> Qb4
> Bd1
> 36.
> Qxa3
> exf4
> 37.
> gxf4
> Bg4
> 38.
> Kf2
> Kd7
> 39.
> Ke3
> Kc6
> 40.
> Qb4
> Bh3
> (87.95 Mate in 23) Checkmate is now unavoidable. Be6 was best.
> 40...Be641.f5Ba242.Qa4+Kc743.Qxa2Kb644.Qe6+Ka545.Qd5+Kb646.Qd8+Kc547.Qd4+
> 41.
> e5
> ...
> (Mate in 23 16.91) Lost forced checkmate sequence. f5 was best.
> 41.f5Bg442.Qd4Bh543.Kf4Kb544.f6Bg645.Kg5Bf746.Qd7+Kb647.Qxf7Ka6
> 41.
> ...
> Bf5
> 42.
> Qd4
> Kc7
> 43.
> Qd6+
> Kb7
> 44.
> Kd4
> Bg4
> 45.
> Kc5
> ...
> (Mate in 8 28.37) Lost forced checkmate sequence. e6 was best.
> 45.e6Be246.f5Bh547.f6Bd148.f7Ba449.f8=QBc650.Qfb8+Ka651.Qxc6+Ka5
> 45.
> ...
> Bf3
> 46.
> Qb6+
> Kc8
> 47.
> Kd6
> Bb7
> 48.
> Qc7#
> White wins by checkmate.
>
> In the analysis board it realizes it's a mate in #4 after Kc5. Which is a faster mate than e6!
Not on my analysis board.
@IndigoEngun said in #3:
> This is an artifact of the engine running at too low a depth, but it wouldn't be an issue if the general issue of flagging completely winining moves as inaccuracies was fixed.
>

I don't think it's as simple as that. Sometime "completely winning moves" should be called inaccuracies or even, dare I say it, mistakes.

As one example, how about this position from Reshevsky - Fischer, Los Angeles 1961. Black to play.



Full game here: www.chessgames.com/perl/chessgame?gid=1008403

Fischer played 49...g1=Q? This allowed Reshevsky to queen his own pawn with check and initiate a lengthy series of queen checks before they finally ran out and he resigned. Instead, Fischer should have played 49...Ke4! 50.b8=Q Ra2+ and mates.

Now, 49...g1=Q still won. Fischer called it "a hasty slip which, fortunately, still wins" in "My 60 Memorable Games". He was simply lucky that he was subsequently still eventually able to escape his opponent's queen checks by the skin of his teeth. I certainly think that software should be flagging Fischer's 49th move as an inaccuracy or even a mistake despite it still leading to a completely winning position.
Sometimes the move that's preferred by the engine or the move that leads to the shorter checkmate may also lead to much trickier positions. Because the shorter checkmate may involve getting into a difficult sequence with non-obvious only-moves to not lose the advantage, whereas the "inaccurate" move leads to a comfortable position with a safe king and a clean rook up.

So while an argument can be made about the practicality of moves, and how some moves that are technically good are inaccurate from the perspective of an imperfect player which may slip up, it works both way. A higher Stockfish evaluation or especially a checkmate evaluation (in more than 1 or 2 moves) does not guarantee at all an easier path to converting the win.

You'd need to run something like maia to predict what kind of errors the imperfect player may be likely to play, but that's also dependent on the player's strength. What's a risky sequence for a 1000 elo player may be a breeze for a 2000 elo player. It's too complicated to be integrated in the standard post-game analysis.

In the meantime, spurious inaccuracies are much more common than the rare "winning but not practical" moves being flagged. This thread's example even has the move leading to the shortest possible checkmate being flagged as inaccurate.

I recall that the inaccuracy/mistake/blunder flags are supposed to depend on the change to the winning likelihood, but when dealing with very high (absolute) evaluations it cleary doesn't work like this.
Agreed completely with what you write in #5 @IndigoEngun . It works both ways.

I would not support even attempting to let the software make some judgment about human playing difficulty and basing "inaccuracy" labels on that. Let's leave that to chessdotcom to make a mess of. It isn't feasible.

What I do advocate is leaving the software to make its own judgment on the basis of its own evaluation of the positions and leave it that (errors caused by inadequate search depth as in the position in the original posting notwithstanding). Don't even attempt to correct things. And users of such software should always be aware that it's a tool, not an oracle, and to interpret it accordingly.

This topic has been archived and can no longer be replied to.