what to do when all depths give the exact same score?

[sandermvdb]

For example in the following position:

[d]8/8/8/5Q2/8/7k/1K5p/8 b - - 0 104

This is a draw but my engine does not see it and I do not want to hardcode all these combinations. It should be quite easy to see because every search at depth >=12 gives the exact same score: -839.
Are there some best-practices for this? For instance check if the score of the previous n depths are exactly the same and divide the score by 2 subsequently if that is the case?

[Ras]

I do not want to hardcode all these combinations

You can use table bases. Otherwise, hardcoding is still a good idea because it enables the engine to see already in the search tree before that this position is draw. Either the engine could be heading for that (with Black) or try to avoid it (with White).

It should be quite easy to see because every search at depth >=12 gives the exact same score: -839.

That would be the same for any forced mate, too.

[bob]

Two comments.

(1) using endgame tables is the answer here as it will handle all of the oddball cases with reduced material;

(2) you ought to be able to find the draw via search. I just tried Crafty and with one thread on my 1.7ghz MacBook, it takes less than 3 seconds to come up with a repetition draw score... If you don't find it via search, you probably need to look there to see why not...

But for the general case, why not use endgame tables? SYZYGY is easy to use, won't slow you down, and will let you find lots of things you would never find otherwise.

[sandermvdb]

Two comments.

(1) using endgame tables is the answer here as it will handle all of the oddball cases with reduced material;

(2) you ought to be able to find the draw via search. I just tried Crafty and with one thread on my 1.7ghz MacBook, it takes less than 3 seconds to come up with a repetition draw score... If you don't find it via search, you probably need to look there to see why not...

But for the general case, why not use endgame tables? SYZYGY is easy to use, won't slow you down, and will let you find lots of things you would never find otherwise.

Sorry, but I don't want to use endgame tables.
Regarding the draw via search, white thinks it has an advantage, so why would it 'accept' a draw by repetition?!

[Ras]

If you don't find it via search, you probably need to look there to see why not...

Because the queen can vertically come close to the king, giving checks, then going away from the king horizontally, also giving checks, and finally move over somewhere to a8 and come close to the king diagonally, always giving checks. Or in some other permuation of that approach.

Since the queen will not be on the same square, there will be no immediate repetition visible. Like this one:

1... Kg2 2. Qg6+ Kh1 3. Qe4+ Kg1 4. Qg4+ Kh1 5. Qf3+ Kg1 6. Qg3+ Kh1 7. Qe1+ Kg2 8. Qd2+ Kg1 9. Qe3+ Kg2 10. Qe4+ Kg1 11. Qd4+ Kg2 12. Qd5+ Kg1 13. Qc5+ Kg2 14. Qc6+ Kg1 15. Qb6+ Kg2 16. Qb7+ Kg1 17. Qa7+ Kg2 18. Qa8+ Kg1 19. Qa1+

My engine judges this position as +0.07 (for White) from depth 2, without table bases.

[sandermvdb]

My engine judges this position as +0.07 (for White) from depth 2, without table bases.

So you recognize that it is a draw?

[Ras]

So you recognize that it is a draw?

Yes. Rook or bishop pawn on 2nd/7th rank with its king close by and the other king sufficiently far away, including who is to move, that's recognised as draw. I've experimented with another, table based engine to figure out what the critical distance of the attacking king is.

I've also hardcoded rook versus pawn in that situation because otherwise, the engine gets the "great" idea to underpromote to rook instead of queen in a pawn race as to avoid this queen vs. pawn draw.

Other underpromotions to a minor piece (which sidestep both the queen and the rook draw here) are already blocked out because if one side has a minor piece while the other has a pawn, the side with pawn gets scored better even if it is down as per the material bilance.

Elementary mates are also hardcoded, including N+B, and there is an internal bitbase for K+P vs. K. The draws with B or N against R are also in there.

[Evert]

Are there some best-practices for this? For instance check if the score of the previous n depths are exactly the same and divide the score by 2 subsequently if that is the case?

There is no best practice when the root position is a dead draw. Only cosmetic fixes that report a 0.0 score.

Best practice is to recognise that this is a draw before it appears in the root, either by a special evaluation, a tablebase or general code to detect fortress draws. The latter of these is the most general, but also the hardest.

[Sven]

This is a draw but my engine does not see it and I do not want to hardcode all these combinations.

An engine that does not know about certain exceptions where a significant material advantage can't be converted into a win will have a hard time to find the draw via search, when also not using tablebases. Therefore you should consider to encode some of the most important exceptions in your evaluation function.

But even then I don't think it will be very easy to find the draw by search. My engine Jumbo does not find the draw in the position given above within several minutes (I stopped at depth 28).

Most important, however, should be to recognize these exceptions when they occur somewhere down the tree, not at the root, since this allows the engine to avoid trading down into some drawn endgames. For that purpose scaling down the score (e.g. divide by 4, 8, 16) in these cases should be sufficient.

It should be quite easy to see because every search at depth >=12 gives the exact same score: -839.

All iterations returning the same score does not necessarily indicate a draw.