draws

[ericlangedijk]

Hello all, I am almost ready to release my chessengine, which has just HCE for version 1, but playing quite ok. I guess around 2850.
There are however still some loose ends to solve and maybe you have some tips from experience.
For example. It thinks this is winning while other strong engines just see a draw.
5k2/8/4P3/6Bb/B7/b1K5/8/8 b - - 0 57
Also the engine often does not see saving perpetual checks in winning positions.
It played Bc6 allowing Rh8! forcing a draw.
position fen R7/3bp1k1/1q4pp/3pPp2/2pP3P/6P1/1rNQ1PK1/8 b - - 6 48 moves d7c6
The engine also does not see Rh8 when entering this position.
What is the best way to handle repetitions? (I have a repetition table in place).
Where is the trick? What is the mistake?
Any tips welcome. Eric

[hgm]

Normally for moves that reach a position that has occurred before you would not search them, but give them a draw score instead. (Usually 0, but there could be a contempt score.) That should recognize parpetual checks., and if it doesn't there must be a bug in the implementation. The example you give is not a straightforward perpetual check. Black does not have to capture the Rook, and can last many moves with a slightly positive score (according to Fairy-Max) before any repetition occurs.

[ericlangedijk]

The obvious ones it recognizes and handles well...
Debugging recursive stuff in a billion tree is not too easy.
Work to do...

[Uri Blass]

Normally for moves that reach a position that has occurred before you would not search them, but give them a draw score instead. (Usually 0, but there could be a contempt score.) That should recognize parpetual checks., and if it doesn't there must be a bug in the implementation. The example you give is not a straightforward perpetual check. Black does not have to capture the Rook, and can last many moves with a slightly positive score (according to Fairy-Max) before any repetition occurs.

In the relevant example Rh8 force a draw.

Black can play g5 but after Rxh6 it is an obvious draw.

I do not see many moves with positive score and I wonder what fairymax can see.

Trying to avoid repetition seems bad for black and I gave some possible lines part are bad for black.

[pgn][Event "Computer chess game"]
[Site "DESKTOP-7QE6S12"]
[Date "2025.11.07"]
[Round "?"]
[White "àåøé"]
[Black "Movei v0.08.438"]
[Result "*"]
[BlackElo "2400"]
[Time "21:13:55"]
[WhiteElo "2400"]
[TimeControl "60+3"]
[SetUp "1"]
[FEN "R7/3bp1k1/1q4pp/3pPp2/2pP3P/6P1/1rNQ1PK1/8 b - - 0 48"]
[Termination "unterminated"]
[PlyCount "8"]
[WhiteType "human"]
[BlackType "human"]

48. ... Bc6 49. Rh8 g5 (49. .. Kxh8 50. Qxh6+ Kg8 51. Qxg6+ Kf8 52. Qxf5+)
(49. .. f4 50. Qxf4 Kxh8 51. Qf8+ Kh7 52. Qf7+) 50. Rxh6 Kxh6 51. Qxg5+ Kh7
52. e6 (52. Qxf5+ Kg8 53. Qg6+ Kf8 54. Qf5+ (54. e6 Be8 55. Qh6+ Kg8 56.
Qg5+ Kh7 57. Qxe7+) 54. .. Ke8 55. Qc8+ Qd8) *
[/pgn]

[ericlangedijk]

Yep. And what bothers me most is that my engine never ever finds Rh8

[hgm]

The obvious ones it recognizes and handles well...
Debugging recursive stuff in a billion tree is not too easy.
Work to do...

The way I do that is to put a conditional ptint statement immediately after UnMake, which prints move, score as text and numeric encooding), and bestScore. The condition for printing is that the path to the node (kept in an global array of moves path[ply], filled during MakeMove) equals the first part of of a similar array initialized to the path you want to trace (e.g. given as an argument to the executable, to avoid recompiling for every step that extends the path).

With that infrastructure in the engine I just start with an empty path to print the move list in the root. Then I extend the path with the move that I think has a wong score, to zoom in on the node where this score comes from. This way I get to the source of the problem pretty quickly, irrespective of the size of the tree. I have found bugs that manifested themselves at ply=23 this way without too much trouble.

Hashing might cause a light complication; if a node where the print condition is satisfied suffers a hash cutoff I print the hash key (or index) of that node. At the point where a hash probe hits on that key I print the retreived score and the path to that key. So that I can resume tracing the problem from that path.

Of course the problem in your case need not be that the draw score is not found, but just that it overestimates the score of a black deviation at some depth so much that it is better than draw, and makes black avoid the repetition.

[ericlangedijk]

Thanks I tried in the past and will retry that.
Problem could be that moves are pruned but it should be possible to track the problem that way yes.