Basic endgame tests

[RayLeeIsmay]

I'm working on adding some simple endgame knowledge to my engine. Does anyone have a test suite of very simple endgames? For now I'm thinking 4 total pieces or less.

[hgm]

What kind of knowledge do you have in mind? There is general knowledge based on piece composition (such that KRKB is usually a draw, and KBK always), and there is detailed knowledge based on actual piece locations (such as which color you have to drive the King to in KBNK, or which KQKP positions are draw). Often the knowledge isn't really helpful unless you also do something special for the end-games that could convert to it. E.g. if you recognize KRKN as very drawish, the engine would just refuse to take the Pawn in KRKNP, and would still imagine itself to have a nearly winning advantage.

[RayLeeIsmay]

Right now I'm working on special evaluation functions to handle certain endgames. For instance, if we have KRk or KPk or KRPkr (starting with easy examples), eval can call another function that handles that endgame which isn't usually called.

[dangi12012]

eval can call another function that handles that endgame which isn't usually called.

You mean you want to probe a tablebase?
https://github.com/syzygy1/tb/tree/master/interface
https://tablebase.lichess.ovh/tables/standard/

[hgm]

For KRK you usually do not need special knowledge. Just the general knowledge that in the end-game a king is better in the center and worst in the corner (an a Rook is equally good anywhere) should suffice. For KBBK it would help to increase the centralization score for a bare King, because Bishops are not neutral, and you don't want the engine to prioritize putting both of these in the center. KPK is tricky, because you would want to know whether it is win or draw immediately when you hit it, and not after a search so deep that it can only see it after the game is already decided. Some engines have a built-in bitbase for this (a 32KB table). At the very least you should recognize defending King 1 or 2 steps in front of Pawn, and 3 ranks in front of with opposition as draw. KRPKR might be hard to determine by rule (I never tried that); an EGT might be the best solution there. If you manage to recognize sufficiently many of the draws it wil enormously speed up the search in case of a win. (I saw the same thing in KPK.)

[Henk]

Endgames can be very misleading even an endgame with a bishop and say an h pawn of the wrong color may not be a draw when you can keep opponent king out of the corner.

Maybe best to start with KP endgames and KR endgames but boring.

I read KNkr is a draw when played correctly. Sounds difficult as well.

[likeawizard]

Right now I'm working on special evaluation functions to handle certain endgames. For instance, if we have KRk or KPk or KRPkr (starting with easy examples), eval can call another function that handles that endgame which isn't usually called.

Sounds like you want to create an eval function that behaves differently in the opening/middle game and have special functionality called in cases where you determine the game to in the endgame phase.

I think this is a bad approach as it causes Evaluation Discontinuity - in your search you might evaluate one position with one eval function and the next with a flip of a switch with another one, which can cause evaluation to have disjoint jumps in logically continuous variations, which is not a good thing. https://www.chessprogramming.org/Evalua ... continuity

Still having special evaluation for endgames is a good idea but it should not be a distinctly different evaluation call but instead it can be achieved with a game phase metric and a tapered evaluation function. That means you have a value that continuously determines the bias between two openingEval vs endgameEval
https://www.chessprogramming.org/Tapered_Eval
https://www.chessprogramming.org/Game_Phases

I have a very naive and yet not the best weighted implementation of this. I always evaluate the king safety (distance from the center and proximity to friendly pieces and penalties to proximity to opponent pieces) and king activity which is the average of king centralization and proximity to the opponents king.

It is a very naive implementation but observing some games I can see that in early stages the king mostly sticks to the back rank and as pieces fall off it starts to move up. This is not rocket science but even at very low depths of my engine it can comfortably mate with KRk. As it seeks to maximize its king activity and minimize the opponents activity. This results in the all familiar checkmating pattern of using the king and rook to push the opposing king in the corner. It produces the desired effect without having any hardcoded patterns that could create strange side effects.

[Sazgr]

Right now my engine just shuffles pieces around until the mate is sufficiently close by chance (mate in 6 or less usually). With high enough depth and a transposition table it works decently.

[hgm]

Nothing wrong with an evaluation discontinuity. If you lose a knight the evaluation also jumps discontinuously by more than 300 cP. King Safety can be entirely different depending on whether the Queens are still on the board, all else being the same. A position can become completely drawish by trading the last Pawn.

[likeawizard]

Nothing wrong with an evaluation discontinuity. If you lose a knight the evaluation also jumps discontinuously by more than 300 cP. King Safety can be entirely different depending on whether the Queens are still on the board, all else being the same. A position can become completely drawish by trading the last Pawn.

Isn't it tho? Losing a knight does not really fall under evaluation discontinuity to my understanding.
Also king safety should depend whether the queens are on the board or not. It should also matter when queens and rooks and bishops are on the board as opposed to just queens and bishops. But those changes should be gradual I believe.
And your point about draws should be under consideration in the eval function with material imbalances or insufficient material.

With my basic understanding evaluation discontinuity is a problem the transition from middle game eval to endgame eval is accomplished in an ungraceful manner. Where a continuous improvement of the position can at an arbitrary point switch to a different evaluation model and completely change the picture. Wouldn't this result in the search algorithm exploring potentially good positions only to flip back and forth. Isn't there value in variations progressing more gracefully and continuously?