endgame frequency

[kbhearn]

* KRKP: My engine doens't know the drawing cases here, so I fear that in some situations the KRPKR knowledge would be rendered useless by the fact that the search will stupidly go into a KRKP that is misevaluates.

The chance of this should be miniscule as the only way to make that conversion is for the stronger side to throw away a rook, and there's very few positions where the pawn side of KRKP is winning (and i'd assume with no special knowledge, the search would in fact assume the pawn side is losing). Where KRKP knowledge may become important to help the search out is in KRPKRP endings where it's routine that one side queens their pawn and forces a sac and the resulting positions may result in either draws or wins for the side with the remaining rook (and the odd short tactical loss with an unfortunately positioned king and rook).

[lucasart]

* KRKP: My engine doens't know the drawing cases here, so I fear that in some situations the KRPKR knowledge would be rendered useless by the fact that the search will stupidly go into a KRKP that is misevaluates.

The chance of this should be miniscule as the only way to make that conversion is for the stronger side to throw away a rook, and there's very few positions where the pawn side of KRKP is winning

You're right.

Nw the hard part is figuring out when a KRPKR is a draw. I would rather use a conservative rule that doesn't risk detecting false positive for the defending side. I'm trying to understand the KRPKR from Wikipedia, and all I've understood so far, is that it's very complicated...

Precise play is usually required in these positions. With optimal play, some complicated wins require sixty moves to either checkmate, win the defending rook, or successfully promote the pawn (Speelman, Tisdall & Wade 1993:7). In some cases, thirty-five moves are required to advance the pawn once (Thompson 1986).

[Evert]

Basically, you want to recognise these:

• The Lucena position is a known win
• The Philidor position is a known draw
• The back-rank defence draws (in many cases)

Recognising those is fairly straightforward, but the tricky part is that you also have to recognise positions that are one ply off from reaching those, otherwise the engine will "lose the draw" after it makes a move only to recover it a move later (hopefully). This causes nasty oscillations in the evaluation.