Author: guy haworth
Date: 02:23:12 03/04/01
Go up one level in this thread
The phrase 'endgame tablebase' is a little misleading. It makes the EGTB sound
like a complex data-structure.
It is in fact two simple 'vectors' - 1-dimensional lists - of integer values,
one for wtm and one for btm. You could think of these values as going from zero
to N, [0, N].
What each value represents can depend, in part, on the endgame that you are
computing and on the file being indexed, wtm or btm. During and after the
generation process, one needs, say
0 == drawn or 'theoretical value not determined'
1 == 'broken' position, one which the generator can see is illegal
2 --> N1 == side-to-move wins in 'k-1' moves
N1 + 1 --> N == stm loses in 'k-N1-1' moves
This is the basic idea.
Rob Hyatt gave the basic idea about indexing a 64^n-size space but Eugene
Nalimov has many improvements on this, see ICGA_J v23.3 (2000) paper by Nalimov,
Heinz and myself. His indexes can be many times smaller than the basic 64^n
idea and this economy is needed for 6-man endgames.
There are more sophisticated ideas like:
a) splitting up an endgame according to Pawn-position profiles
b) splitting up an endgame by B-square-colour profiles
c) measuring depth in plies rather than moves to distinguish between some
so-called 'equi-optimal' moves
but these are 'frontier ideas' now being tested.
The approach above works for many games including varients of chess like 'Losing
Chess' and positions with 'Generic Knights' which execute x-y moves on n*n
boards.
G
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.