endgame programming

[Anan Ke]

Hi,

I am not interested in adding tablebase support to my engine, but I am interested in rule-based/heuristic endgame programming. I've looked around for information on this approach and have found next to nothing in the way of literature, does anyone know of any resources, whether for particular 4/5 piece endgames or not ? Or has this approach been completely abandoned in favour of tablebases ?

[Joachim Rang]

Hi,

I am not interested in adding tablebase support to my engine, but I am interested in rule-based/heuristic endgame programming. I've looked around for information on this approach and have found next to nothing in the way of literature, does anyone know of any resources, whether for particular 4/5 piece endgames or not ? Or has this approach been completely abandoned in favour of tablebases ?

look in the source code of Fruit, there are some heuristics concerning basic endgames.

regards Joachim

[Ross Boyd]

Hi Anan,

Or has this approach been completely abandoned in favour of tablebases ?

No, its essential to have a good heuristic endgame evaluation, otherwise your engine can play into drawn endings thinking its winning (and visa versa). You need to recognise these sorts of endings long before you get to 5 or 6 pieces left on the board.

Also, tablebase access is way too slow if used in the quiescence search (without heavy constraints)...

On the subject of egtbs I don't think they are often used to their best advantage. Most engines just count the pieces and probe after a capture where the piece count is <= 5 (assuming 5 man egtbs). Some probe only at the 1st few plies of search etc.

I think (if the weaker sides pawns aren't too advanced) the egtb can be probed when the piece count is HIGHER than 5...

For instance, if the weaker side has two pawns and the stronger side has qrb, normally the egtb would not be probed (because pieces>5). Why not probe using KPPKQ in this case? You can prune everything under that node. You just have to watch out for positions where the extra pieces on the strong side work against you (usually when the pawns are close to promotion).

I haven't tested this so I'm talking theoretically but it should help overall regardless of the occasional misevaluation.

Comments anyone?

Ross

[Tony van Roon-Werten]

Hi Anan,

Or has this approach been completely abandoned in favour of tablebases ?

No, its essential to have a good heuristic endgame evaluation, otherwise your engine can play into drawn endings thinking its winning (and visa versa). You need to recognise these sorts of endings long before you get to 5 or 6 pieces left on the board.

Also, tablebase access is way too slow if used in the quiescence search (without heavy constraints)...

On the subject of egtbs I don't think they are often used to their best advantage. Most engines just count the pieces and probe after a capture where the piece count is <= 5 (assuming 5 man egtbs). Some probe only at the 1st few plies of search etc.

I think (if the weaker sides pawns aren't too advanced) the egtb can be probed when the piece count is HIGHER than 5...

For instance, if the weaker side has two pawns and the stronger side has qrb, normally the egtb would not be probed (because pieces>5). Why not probe using KPPKQ in this case? You can prune everything under that node. You just have to watch out for positions where the extra pieces on the strong side work against you (usually when the pawns are close to promotion).

I haven't tested this so I'm talking theoretically but it should help overall regardless of the occasional misevaluation.

Comments anyone?

Ross

I'm afraid there's no point in probing for this case. If you have qrb gainst pp where the 2 pawns are not very far, the score should already be > +15. What would a checkmate score add ?

What could be interesting is KNKPPP fe. If you probe the KPPK's and find out they can't win, you might be able to do something usefull with this knowledge like trading the knight against the right pawn.

Tony