endgame frequency

[lucasart]

Has there been a study on the %age of computer chess games reaching each 4-men and 5-men endgame ?

I'm wondering which endgame knowledge should be added to my engine. And I don't want to clutter it with code that is only useful in very very rare endgames. For now, all I have is:
* KPK: exact using bitbase
* KBPK: general heuristic that detects a good portion of the draws, all the other draws are never many good plies away from the undetected ones

So I'm wondering what else I should do. For example:
* KPKP
* KRKP
* KQKP
* KRPKR

I haven't got any numbers, but intuitively I would say that endgames with a rook are probably quite likely.

[Edmund]

http://www.open-aurec.com/wbforum/viewtopic.php?t=3987

[petero2]

Has there been a study on the %age of computer chess games reaching each 4-men and 5-men endgame ?

I'm wondering which endgame knowledge should be added to my engine. And I don't want to clutter it with code that is only useful in very very rare endgames.

This is not exactly what you asked for, but when my engine was fairly new I wrote a script that parsed a pgn file and for each game reported the result of my engine (0,1/2,1), the lowest and highest search score my engine got during the game, and the move numbers where the lowest/highest score happened.

I then filtered this list to get the games where my engine did not win, sorted those games according to the highest score and manually examined the most "disturbing" games.

This analysis led me to implement special evaluation for KBPK, KRKP and KQKP. I think it also made me find some non-endgame related bug, but I don't remember for sure.

[Evert]

So I'm wondering what else I should do. For example:
* KPKP
* KRKP
* KQKP
* KRPKR

I haven't got any numbers, but intuitively I would say that endgames with a rook are probably quite likely.

Yes.
I think 10% of all games is the typical figure that is mentioned. I have all of those except KPKP in Jazz (I should probably add that one too). KQKP isn't worth very much (it is worth something of course but the number of games where it plays a role is small), I think, since it's usually won quite easily. However, if you don't know the drawing positions it can become a bit embarrassing.

Of those four KRPKR is probably the most important one. The general heuristics are not too complicated. Two important points to realise: when playing the position in practice, the engine will find the correct winning plan ("build a bridge") fairly easily, you don't need anything for that. What you need to avoid is trading down into a drawn position from a winning one, so that's what the evaluation has to do for you.

[mcostalba]

Has there been a study on the %age of computer chess games reaching each 4-men and 5-men endgame ?

You don't need to reach the endgame to make the endgame useful.

Your statement can be rewritten as: what is teh %age of endgames showing up in PV line?

But this says nothing regarding the usefulness of endgame that, for instance could be evaluated only in a side line and then perhaps rejected because endgame was evaluated as a loser one by the endgame knowledge inside the engine.

IMO only real games can prove usefulness of endgames. Of course testing each endgame one by one requires enormous amount of power, but you can bunch together some of them and test if you see some change removing, say 3 of them in a single shot.

[lucasart]

Has there been a study on the %age of computer chess games reaching each 4-men and 5-men endgame ?

You don't need to reach the endgame to make the endgame useful.

Your statement can be rewritten as: what is teh %age of endgames showing up in PV line?

True. In fact, even at non PV nodes, they are just as important

I've never managed to measure the usefulness of such heuristics. Not even KPK. But if they are implemented correctly, they don't cost any elo, and they make the engine look less stupid in some dead drawn endgames. So they are nice, and that's really the only reason why I want to implement more.

By the way, an interesting patch you could test in Stockfish is to remove all the endgame knowledge, with the exception of KPK. I would be curious to see the result.

[lucasart]

when playing the position in practice, the engine will find the correct winning plan ("build a bridge") fairly easily, you don't need anything for that. What you need to avoid is trading down into a drawn position from a winning one, so that's what the evaluation has to do for you.

100% agree. All I'm looking for is a heuristic that tells me when it's "drawish", and use a score divisor "a la Fruit".

[Don]

Probably the most important ending is KRPKR - it occurs frequently and has a relatively high percentage of differing results. A lot of endings are 99% draw or 99% wins, etc. Those are less important.

Most programs will play KRPKR correctly so the primary benefit is not playing the ending but evaluating it at end nodes. If your program "commits" to some sequence that ends in one of these endings you want to know for sure that you are not throwing away half a point.

Don

Has there been a study on the %age of computer chess games reaching each 4-men and 5-men endgame ?

I'm wondering which endgame knowledge should be added to my engine. And I don't want to clutter it with code that is only useful in very very rare endgames. For now, all I have is:
* KPK: exact using bitbase
* KBPK: general heuristic that detects a good portion of the draws, all the other draws are never many good plies away from the undetected ones

So I'm wondering what else I should do. For example:
* KPKP
* KRKP
* KQKP
* KRPKR

I haven't got any numbers, but intuitively I would say that endgames with a rook are probably quite likely.

[Michel]

All I'm looking for is a heuristic that tells me when it's "drawish", and use a score divisor "a la Fruit".

The most important heuristic is that if the defending king is in front of the pawn then it is generally draw.

There are also some rules about the distance the defending king has to be cut off for a win. These are not quite accurate but give some idea.

[lucasart]

Probably the most important ending is KRPKR - it occurs frequently and has a relatively high percentage of differing results. A lot of endings are 99% draw or 99% wins, etc. Those are less important.

Most programs will play KRPKR correctly so the primary benefit is not playing the ending but evaluating it at end nodes. If your program "commits" to some sequence that ends in one of these endings you want to know for sure that you are not throwing away half a point.

OK, I'll look into the KRPKR. The only thing that worry me is that a KRPKR can result in:
* KPK: OK I can find the draws with the bitbase
* KRK, KRKR, KRPK: trivial
* 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.

Perhaps this problem has a very small chance of occuring though.