Weird engine behaviour

[eligolf]

When testing my engine versions against each other I found one weird behaviour, which got even weirder when I looked at the position with a few engines. The position I am talking about is this:

[d]8/8/1p6/7p/pr3k2/8/6K1/1r2R3 b - - 0 61

Black to move and has a win in 3 moves: 1. ... Rb4-b2+ 2. Kf1 Kf3 3. Rxb1 Rxb1# (or some other variation of this).

My engine outputs this from a search to depth 7:



As you can see it find the mate in 3 at depth 4 (it has to see if there are valid moves or not at depth 4 to know if there is a mate in 3). But then it somehow forgets this and finds a mate in 4 later on. Okay, so a bug in my engine probably? Then I tried it with lichess editor: https://lichess.org/analysis/8/8/1p6/7p ... -%200%2061 and guess what, it only finds the mate in 4, at depth 23!

I then put it up in SF in Arena and it found the mate in 3 immediately. Maybe from tablebases or something because it did it at depth 1 according to Arena output...?


So 2 questions to the gurus here:

1. When my engine finds a (positive) mate at a depth, should I immediately stop at that depth and just return the move that gives mate? Since it will not find mate in less moves when going higher/deeper (if I make sense).

2. Is this due to null move and the nature of the zugzwang situation after 2. ... Kf3? And the null move logic?

[hgm]

Depending on how you implemented null move this could be a zugzwang problem: after 2. Kf3 white can avoid to be mated in one by passing his turn. If you do check extension, you would still have 3 ply left at that point.

And no, you should not play the first mate you find. Often the first mate the engine sees is a longer one (e.g. because of check extensions). It would for instance run the risk that in KQK you would see the mate-in-2 always before the mate-in-1, with as a consequence that it would never checkmate at all, but always delay it 'one more move'.

[Sven]

Hi Elias,

the version you showed me via PM correctly finds the mate in 3 (= mate in 5 plies!) at depth 5 and does not forget it. Prior to depth 5 it displays Rxe1 as best move. That version has nullmove disabled. So I suspect that you are now testing a version where nullmove is active and does not work as expected.

At depth 4 you can (usually) only find a mate in more than 4 plies with a working check extension feature.

Engines without pruning should normally find all forced mate-in-N-plies during iteration N or earlier. So you might stop the search after iteration N if you have found a forced mate in at most N plies
a) with odd N: for the engine itself, or
b) with even N: for the opponent.
But as soon as you implement some pruning method, like futility pruning, razoring, LMP, or simply null move pruning, this may become dangerous.

[eligolf]

Thank you for the input guys. That is both valuable information. Seems like a nullmove thing yes, will have to consider to have another condition to make a nullmove.

But isnt it strange that stockfish on Lichess can't find the mate in 3 and goes for mate in 4 instead?