Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Tablebase generation - what am I overlooking?

Author: Heiner Marxen

Date: 09:42:39 02/14/02

Go up one level in this thread


On February 13, 2002 at 22:27:07, Russell Reagan wrote:

>On February 13, 2002 at 18:48:18, Angrim wrote:
>
>>Not only is the file compressed, but the positions are not stored in it.
>>There is no point using 18 bits to store a position, when you know what
>>the position was from the index into the file.  Only the positions value
>>is stored in the file.
>>Your design was pretty good for someone who hasn't studied the currently
>>used methods though.
>>
>>Angrim
>
>I'm not quite sure how all of this works. If there is some published material on
>this topic or websites that explain it thoroughly feel more than welcome to
>point me to those sources. I'd like to get a good understanding of what's going
>on with tablebases.
>
>To me, I don't see how you can not store the position in the TB file. I guess I
>can see a way you could make an algorithm that creates the index from the
>position, and then when you look up that index you get the mate distance. That
>makes sense, but just in theory (to me).

Well, this is not just theory, it is the state-of-the-art method to build
these EGTBs.  From a position there is computed an index (which is not
completely trivial, involving symmetry considerations and other stuff),
which is used to directly index a huge array of values, residing on disk.
This is the "simple" case, without compression.
( If you would have to store some value for each of the 12 months, you
  would not store a list of pairs (month-name, value), would you?
  You would somehow translate the month-name into an index 0..11 (or 1..12)
  and directly index an array of dimension 12, right?
  Now neither the names nor the indexes of the months are found in the
  table/array of values.  Wow :-)

With compression, the logical index is somehow translated into the location
and length of a physical block of compressed data, which after decompression
is accessed by the index (reduced by the index of the block start).

If you add table base file selection, provide for values which do not fit into
a single byte, and insert a good caching sceme, you have an uptodate EGTB
implementation.

> Hopefully you guys will be able to
>refer me to some papers published on this or some good websites.

Hmmm, I do not remember any tutorial on how to build/design EGTBs.  Sorry.
About good indexing methods you may read from Ernst A. Heinz (chapter II.5)
    http://supertech.lcs.mit.edu/~heinz/node1.html
They may have appeared a more recent article in the ICCA/ICGA-Journal,
but I'm not sure about that.

>Thanks for all the help so far,
>Russell

You are welcome!

Cheers,
Heiner



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.