Mates that are difficult for engines

Is there a reason a queen doesn't work at the beginning?

There certainly is.

Oh I see, the queen can't break down that fortress the same way a knight can, cool puzzle.

1.c8=Q ends up being a fortress. With the underpromotion you are able to control the critical square g8 which keeps the black King from that square so the black Rook is boxed in by the black King and unable to free the position by bringing the Rook out .

Here is yet another amusing, repetitive move sequence that engines have trouble with. This time it's a mate in 74:

Here's a nice white to move and mate in 15 that gives engines a very difficult time:

.

What is interesting is that this one is extremely easy for humans! The solution is completely determined by the need to provide a bodyguard for the wK when marching forward! And I bet there is an even lighter setting for this idea.

You're just smarter than Stockfish in some situations

Thnx! Smartness is about (meta-)heuristics. 10 years ago I was told that SF uses relatively few heuristics, so it is dumb. Perhaps it wasn't true or isn't true any more with the addition of NN strategies.

In the domain of composition chess my skills are not unusual. There are thousands of problemists who solve such a problem in let's say 10 minutes! I am not in the top 100 solvers of the world

Some years I was #1 in the half-rating list of the WFCC since I participated in just 1 solving contest for many years, while the minimum for a full rating is 2. And then I was so stupid to participate in another solving event. And now I am nowhere

White to move and mate in 23:

Here is a mate in 31 with 3 bishops, can your favorite engine find a mate in 31 here?:

Here is an extrmely humorous one that you and me can solve easily with just a quick look, however most engines (but not all) struggle with this one:

What kind of 7 man TB? (As in DTM, DTC, DTZ(50)).

@DesperateKingWalk

The reason I ask is

(i) The Lomonosov DTM tables were sabotaged and I'm interested to know if there are any 7 man DTM tables anywhere in the world.

(ii) If they're not DTM tables they're not necessarily much use for mate in n problems because the number of moves to mate is not their objective. For example the fastest this mate in 2 can be achieved using Syzygy optimal moves is 6 moves.

In fact the mates using Syzygy optimal moves have no fixed length. Here is another example of the above mate that also uses Syzygy optimal moves. (This is probably far from the stoutest defence - it would be an interesting challenge to find how long Black could last against Syzygy optimal moves.)

The question here is: engines find it difficult to do what with the mate?

There has been a lot of references to engines solving mates, but I don't think they do unless they're mates in a very few.

Solving a mate position involves finding a forced mate. A forced mate is not a single game sequence, rather what I'll call "a half tree" ("a forest with half foliage" would be more accurate, but also more typing).

To illustrate, in the following position SF may play the moves shown against an opponent (possibly itself).

That is not a solution it's just SF mating the opponent, as it usually does from the starting position, which also doesn't qualify as a solution of that position.

A solution would be finding the following forced mate or another similar

Here, single selected White moves for each Black response, but all legal Black moves for each selected White move. (The half tree has single yellow lines and branching green lines.) The end positions must all be checkmates.

I think people are mostly assuming, as I did and as I think @Rocky64 assumes in his interesting link, that when an engine declares a mate it has found such a forced mate, but this isn't actually the case. Here is Arena/SF15.1 (NNUE disabled) analysing a position.

At time 19.09 it announces mate in 42 then almost immediately changes its mind to a valuation of +0.52, even more immediately reasserting mate in 42, only to change its mind again at time 22.07 to a valuation of +10.74.

I think the conclusion here has to be that when it announces +M42, it's lying.

It hasn't found a forced mate, just a partial half tree. Engines in fact don't in general solve mates (especially not @drdos7's).

It's a tablebase win. Interesting since the pawn is past the troitsky line..

It's a Troitzky win (see Collection of Chess Studies 1937).

It is a mate in 38 (as finally reported), but it's anyone's guess if SF15.1 knows that.

The line given includes a Black inaccuracy scrolled off to the right. That in itself doesn't necessarily mean it hasn't solved it at that point, because it's only necessary that all lines in a half tree complete in the specified depth. However, it means that the printed line contains a counter balancing White inaccuracy later since it runs to 38 moves (I stopped reading before that point). But the Black inaccuracy only results in reaching a position in an accurate line faster and it would seem unlikely that it has included both accurate and inaccurate mating lines from the same position in a complete half tree, so I would guess it hasn't actually solved it at the point it's last declaring +M38 even though the value is correct.

Basically it's guessing.

Is that position still a win if it is black to move?

As long as the final outcome is "better" (less moves) than an intermediate mate prediction you can't be sure that SF is lying. It's always possible that it uses some heuristic capable of establishing a ceiling for the DTM without playing any move whatsoever. Unlikely, I admit!

Real lying would be if the final outcome is "worse" (more moves) than an intermediate prediction. That would constitute proof delivered by SF itself that its earlier "mate" was unreliable and wrong. I think, I've seen those cases too so I am happy to rate SF as "criminal".