Too difficult for computers

1949 endgame study by Naiderashvilli, from Irvin Chernev's Practical Chess Endings (perhaps a tad off topic for the book title).

That is super difficult!!!

Maybe Alien can solve it

I love it

I wonder when computers will be programmed to understand how to solve these types of puzzles.

Are you sure that is not with hindsight? If you do analysis of a whole line in an engine, it can use that analysis to inform analysis of an early position in that line (it provides part of the tree). Normally useful, here misleading.

Stockfish 15.1 NNUE used in chess.com's analysis module views this position as equal at depth 20. So does the alternative version of Stockfish it offers.

That's true. When I loaded that mate in 67 problem into Stockfish, it had no clue, even as I was playing through the moves for 40 moves in. But after checkmate, if I rewinded it back to the beginning one move at a time by hitting the back arrow in analysis mode, it would then say M67, but not if I refreshed the position!

That's odd, since unlimited would be expected to add plies after 20.

Did you use the initial position FEN in a fresh analysis? This is crucial.

The Lichess analysis tool which has an entirely adequate limit of 99 ply doesn't do any better. After several minutes I see it at depth 24 with an equal evaluation. Depth 27 cloud analysis does no better.

I am doing this on a not terribly fast i5 machine, but I wouldn't expect a vast difference due to processor.

It is a fact that 41-ply analysis is necessary get a clear evaluation, but the forcing nature of the lines makes it appear doable.

The latter is it.

EDIT: maybe not just that though. The processor certainly helps - that Threadripper could be over 10 times faster than my old overclocked i5!

I can confirm that Stockfish solves it almost instantly just as DesperateKingWalk said, I used the FEN rather than the PGN so the solution was not stored in the hash table, it showed a mate in 47 at the 1 second mark and I let it think for 1 minute where it lowered the mate to mate in 36, but admittedly not a mate in 21, however after going over it quickly it looks like the mate can be shortened to a mate in 19 instead of mate in 21 if white plays on the 11th move 11.Bf7 (11.Bg8 also works here) instead of 11.Bd2, take a look at the my PGN:

Nice improvement! Even more difficult to see: a good bit of assisted analysis.

I am puzzled about the rapid solution compared with the failure (given many minutes) of Stockfish on depth 99 (admittedly an earlier version of the engine, but the idea of selective deeper search is surely not a new one. I am wondering what made your engine search deeply enough, but the online analysis tool fail to do so!

The online version doesn't allow me to use all 20 of the cores that my computer has so that might have something to do with it. Nevertheless it still didn't see the staircase maneuver or the mate in 19 (or 21) .

This is a nice study, on a well-known theme, but also cooked:

2.Bh6 is not mandatory- 2.Kc8/Kc7 works as well.

Apparently Naidareshvili thought that the ending in the following line

is a positional draw, but tablebases do not agree.

For the record, Stockfish isn't the best engine to solve problems and studies. Crystal (which is stockfish with pruning disabled) is a better tool to use.

Thank you for the knowledgeable input. (And to previous examples!)

It is not a fault of an endgame study to have a sideline option for white that leads to a slower mate.

Actually I think this was more of a mate in x problem rather than white to play and win, it is true that 2.Kc8 or 2.Kc7 win, but those moves will not give you a mate in 19.

Here's a link to the problem:

https://www.yacpdb.org/#search/M0s0MXA1cDFwNjg4MUI2MXA2YjFrM0IxLy8vLy8vLy8vLy8vLy8xLzEvMS8w/1

Just to clarify a few things, this is an endgame study by Nadareischwili, not a fastest Mate-in-n problem. Problemists use the shorthand "+" to mean a 'White to play and win" study, and that's what's indicated below the diagram on the YACPDB database: study link.

As mentioned on the database page, there's a dual on White's move 10. Assuming Mazetoskylo is right about the even more serious dual on White's move 2, this is an unsound study. In a study, alternative winning moves by White spoil the problem, regardless of how long they take to mate. See this blog for an explanation of the differences between studies and mate-in-n problems.

There are several duals on move 2 as indicated in my screenshot on this post: https://www.chess.com/forum/view/endgames/too-difficult-for-computers?quote_id=88999653&page=1#comment-88982835 before Mazetoskylo even chimed in and even before my post DesparateKingWalk's post showed a win with a dual on move 2 also. You can basically move White's black dark Bishop anywhere on move 2 where it cannot be captured and still win, and you can move the White King anywhere on move 2 and still win. It's kind of hard for me to believe that Naiderashvili would have overlooked all of these duals. Also I'll add that Naiderashvili had a mate as the solution. Now I'm not disagreeing with you about what the "+" means but if the solution is carried all the way to mate then I believe it is indeed a mate in x problem especially since there are 13 different duals at move 2.

@drdos7. The intended solution of this study ends with a mate on move 21, and this has some minor duals that are sometimes tolerated even in the main line. It's conceivable but extremely unlikely that an unsound study could be turned into an okay fastest-mate problem. Here the unintended mate-in-19 solution is (not surprisingly) rampant with serious duals. Hence changing the problem's task only turns an unsound study into an unsound directmate problem, unfortunately. As a rule, there's even less tolerance for duals in mate-in-n problems than in studies.

Interestingly, I just completed a similar comment on the Saavedra study. There is a minor dual in the white king route (4.Kb3 or 4.Kc3) which is "forgivable" even by strict modern standards but the same dual would kill the composition in a mate-in-n directmate problem!