Author: Dieter Buerssner
Date: 17:02:08 02/07/04
Go up one level in this thread
On February 07, 2004 at 19:38:08, Mike Byrne wrote:
>Excellent idea -- how much space would KNBK, KRK, KQK and KBBK and take. I'm
>thinking this would a nice feature in PDA's that do not use egtb's.
You can do all of those easily by code. For example my kbbk code looks like
this. Note that the bishop side is alway white - the caller prepares this. Also
some arguments not used (it is an entry in an array of function pointers - other
function need that info). x and p are squares of the Bs.
int probe_kbbk(unsigned char **table, int side, int piece1, int piece2,
int wk, int bk, int x, int p, int *score)
{
if (SQ_COLOR(x) == SQ_COLOR(p))
{
*score = 0;
return BB_EXACT;
}
if ((row(bk) == 0 || row(bk) == 7 || col(bk) == 0 || col(bk) == 7)
&& Distance(wk, bk) == 2)
goto possible_draw;
if (side == white)
{
*score = KBBK_WON;
return BB_LOWER_BOUND;
}
if (Distance(bk,p) == 1 || Distance(bk,x) == 1)
{
possible_draw:
*score = 0;
return side == white ? BB_LOWER_BOUND : BB_UPPER_BOUND;
}
*score = -KBBK_WON;
return BB_UPPER_BOUND;
}
The routine never returns a won score in a draw position (checked vs. TBs). It
can return 0 in a won position, in few cases - by using a stale_mate dectection,
it would be even fewer cases. But it is not important for me - the routine is
mainly meant for pruning. With a 0 score it will not be able to prune, probably,
but one depth deeper in the search, it will then. Similar routines for the other
cases you mentioned. Of course, when the position is on the board, one must do
something slightly fancier, to make sure to make progress.
For other more interesting cases, one can easily calculate the space needed. For
example for KRKN (only W/D, assume code detects the few cases where the N can
win) it would be something like:
462*62*61/8 bytes per side to move
With a pawn, make the 462 to 1806. For cases where WDL is needed (for example
KRKP), devide by 5 instead of 8.
On the Web pages of Ernst Heinz, there are 2 nice articles (which I only found,
after I already had implemented most of this ...)
E.A. Heinz.
Efficient interior-node recognition.
In ICCA Journal, Vol. 21, No. 3, pages 156-167, September 1998.
E.A. Heinz.
Knowledgeable encoding and querying of endgame databases.
In ICCA Journal, Vol. 22, No. 2, pages 81-97, June 1999.
Regards,
Dieter
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.