improve endgame and repetition problem

[tcusr]

hi everyone, i need to change a few things before releasing the source code of my engine but i have failed to fix them.
in this game my engine (white) plays against fairymax (does anyone know its rating?) in a 5+3 game and after getting a winning position it decides to just shuffle the queen and thus draw the game.
[pgn]
1. Nc3 {+0,00/8} f6 {+0,11/8 4} 2. e4 {+0,59/7 10} Nc6 {+0,01/8 6} 3. d4
{+0,60/7 9} e5 {+0,08/9 4} 4. Nf3 {+0,56/6 9} exd4 {-0,07/8 7} 5. Nxd4
{+0,66/7 9} Nxd4 {+0,05/9 4} 6. Qxd4 {+0,77/7 8} Bd6 {-0,11/9 9} 7. Be3
{+0,82/7 8} Nh6 {-0,01/9 6} 8. Qd5 {+0,76/6 8} Nf7 {-0,10/8 4} 9. Bc4
{+0,76/6 8} O-O {-0,01/9 6} 10. O-O-O {+0,80/6 7} Be7 {-0,04/9 8} 11. h4
{+0,98/6 7} c6 {+0,08/10 8} 12. Qh5 {+0,82/7 7} b5 {+0,05/9 4} 13. Bb3
{+0,75/6 7} Qc7 {-0,09/9 8} 14. Qf3 {+0,65/6 6} a6 {-0,09/8 4} 15. Bf4
{+0,73/6 6} Qa7 {-0,05/8 4} 16. Qg3 {+0,92/7 6} Re8 {-0,08/8 2,8} 17. h5
{+0,84/6 6} b4 {-0,27/8 2,8} 18. Bh6 {+0,80/6 6} Bf8 {-4,30/11 4} 19. Bxg7
{+1,40/7 5} Qb8 {-5,12/11 4} 20. f4 {+5,29/7 5} Bxg7 {-5,24/11 4} 21. h6
{+6,33/7 5} Kf8 {-5,50/11 8} 22. Qxg7+ {+6,23/7 5} Ke7 {-5,83/10 7} 23.
Qxf7+ {+6,33/7 5} Kd8 {-6,24/11 4} 24. Qxf6+ {+6,23/7 5} Kc7 {-6,80/11 7}
25. Qd6+ {+6,33/7 4} Kd8 {-4,47/11 3} 26. Qf6+ {+6,23/7 4} Kc7
{+0,00/20 2,8} 27. Qd6+ {+6,33/7 4} Kd8 {+0,00/20 2,5} 28. Qf6+ {+6,23/7 4}
{Draw by repetition} 1/2-1/2
[/pgn]
i don't have a transposition table but i don't think it is necessary because it shouldn't even try to randomly move the queen. my evaluation is just counting the possible squares a piece can move to (not even removing friendly pieces) and also adding a bonus if the attacks mask intersects the opposite king mobility, that's it. maybe i should lower the bonus for the queen?

the other thing is that it plays really badly in the endgame, it always tries to hide the king in the corners. even in simple checkmates like KRvK or KQvK, because of the simple evaluation, all the positions look the same and it just plays the first possible move. i fixed it by using a psqt table only for the king but unfortunately it doesn't work with KBNvK. i'd prefer not to hardcode any chess knowledge so specific (unless it's the only solution, of course), so how do i solve this?

i don't know what kind of adjudication do testers use so i'd prefer not to risk losing games for this simple problems.
thank you.

[Ras]

after getting a winning position it decides to just shuffle the queen and thus draw the game.

You need a repetition detection. Just go back from the search tree position in the game notation until you either hit an irreversible move or find the same position hash again. In the latter case, score it as draw. That would have prevented this issue. Ofc, that requires that you store the position hashes in your game history.

What I also have is a 50 moves detection, but it doesn't just score the draw after 50 reversible moves. It starts after 20 "no action" moves and scales the static eval down from 100% at move 20 to a target value of 10% at move 50. The idea is to gradually smoothen the transition instead of hitting the 50 moves wall suddenly. In attack, it prevents panic reactions. In defence, it motivates the engine to stick to reversible moves.

a psqt table only for the king but unfortunately it doesn't work with KBNvK.

It can't because you need two pieces of knowledge. One is that the defending king needs to be driven into a corner. The other is, if this corner is not the colour of the bishop, the king needs to be driven into the neighbouring corner, i.e. along the rim. I use special defending king PSQTs depending on which colour the bishop has, and I reward the attacking king to be close to the defending one.

[tcusr]

after getting a winning position it decides to just shuffle the queen and thus draw the game.

You need a repetition detection. Just go back from the search tree position in the game notation until you either hit an irreversible move or find the same position hash again. In the latter case, score it as draw. That would have prevented this issue. Ofc, that requires that you store the position hashes in your game history.

What I also have is a 50 moves detection, but it doesn't just score the draw after 50 reversible moves. It starts after 20 "no action" moves and scales the static eval down from 100% at move 20 to a target value of 10% at move 50. The idea is to gradually smoothen the transition instead of hitting the 50 moves wall suddenly. In attack, it prevents panic reactions. In defence, it motivates the engine to stick to reversible moves.

i guess it's time to implement zobrist hashing. i've always had problems in the past so i thought i should do it later when the engine is more stable.

a psqt table only for the king but unfortunately it doesn't work with KBNvK.

It can't because you need two pieces of knowledge. One is that the defending king needs to be driven into a corner. The other is, if this corner is not the colour of the bishop, the king needs to be driven into the neighbouring corner, i.e. along the rim. I use special defending king PSQTs depending on which colour the bishop has, and I reward the attacking king to be close to the defending one.

thank you very much. i'll try to see if i can do it with calculations first.

[tcusr]

one consideration, i'm pretty sure fairy-max for standard chess is just micro-max, which is rated ~1950 on CCRL, and i find really strange that my engine (iterative deepening, PVS, quiescence for search and MVV/LVA, best previous ID move for move ordering) is able to play an almost fair middlegame with an engine this strong. there's also to consider my engine is almost 2 times faster but fairy-max is always 2 plies ahead and even more in the endgame (TT).
but this also makes me happy because i wanted to make a 2000 elo engine and as soon as i add null move pruning and a transposition table i will surpass that rating by a lot, i hope. that's easier said than done though.

[Tearth]

What I also have is a 50 moves detection, but it doesn't just score the draw after 50 reversible moves. It starts after 20 "no action" moves and scales the static eval down from 100% at move 20 to a target value of 10% at move 50. The idea is to gradually smoothen the transition instead of hitting the 50 moves wall suddenly. In attack, it prevents panic reactions. In defence, it motivates the engine to stick to reversible moves.

This is an interesting idea, I'm observing in Inanis exactly what you described: pointless traversing through the board for 40 moves because of lack of any plan how to progress more, and then suddenly panic because evaluation has dropped from 3.50 to 0. I will try to test it and see how it's going to change things.

[Ras]

I will try to test it and see how it's going to change things.

I found it important to scale down to 10% target at move 50, not 0%. I don't recall exactly what it was, but there were some corner cases in defending drawn endgames that were only draw if the defending side kept its king on certain squares. The idea of the 10% is to keep some eval in place close to move 50 so that not all moves look the same unless it's actually a valid 50 moves draw.

[hgm]

Fairy-Max is indeed just micro-Max, but the version tested by CCRL is a special compile by Denis Mendozo, which is 70% faster than my own compiles.

Note that for repetition detection you don't really need to implement a transposition table; you just have to calculate a hash key. Of course you could use that key later for accessing a TT.

A poor-man's solution to the repetition problem is to assign a draw score to the move that is the reverse of the move 2 ply earlier, if it, and the previous 2 plies were all non-captures, and the current evaluation is positive, without searching it.

In Joker I just increased the bonus for advancing Pawns after 40 reversible ply in the root. I never saw any advantage in forcing the engine to do a move that i thought to be poor just to avoid a 50-move draw. If it thinks it is ahead, but cannot find progress by shuffling pieces, and can also find no progress by pushing Pawns, it is the best indication you could have that it is misevaluating a drawn position.

[tcusr]

Fairy-Max is indeed just micro-Max, but the version tested by CCRL is a special compile by Denis Mendozo, which is 70% faster than my own compiles.

Note that for repetition detection you don't really need to implement a transposition table; you just have to calculate a hash key. Of course you could use that key later for accessing a TT.

A poor-man's solution to the repetition problem is to assign a draw score to the move that is the reverse of the move 2 ply earlier, if it, and the previous 2 plies were all non-captures, and the current evaluation is positive, without searching it.

i just used the the fairy-max version that came with xboard 4.9.1, that explains why i was able to win sometimes.
people say that a doubling in speed gains about 50 elo, so my fairy-max version is, at worst, 1850 elo, which i don't find bad at all since my engine only has the bare minimum to play decently.

in a 20 games match (3min + 2) it only drew 3 times, so i don't think it's that big of a problem, against weaker engines it will find a way to break in because their responses will not be as good as the one from fairy-max.

[pepechuy]

Hi.

To improve the endgame, you need transposition tables.
Otherwise, the other engines will simply outsearch yours badly.
Without transposition tables, even moderately strong human players can outplay an engine in the endgame.

Greetings.

[tcusr]

this is getting really frustrating because i don't know what i'm doing wrong.
this is how i check repetitions (after the check for depth == 0)

Code: Select all

bool searcher_t::is_repetition(const board_t& board) const
{
	return std::count(vh.begin(), vh.end(), board.hash()) > 2;
}

vh is a std::vector and contains the hashes collected during search. i push the hash during make_move() and pop it in unmake().
the hashes are generated from scratch to avoid problems by doing it incrementally. for the keys i use std::mt19937_64 and the hashes are created correctly as far as i can tell.