Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: EGTB: Better algorithm

Author: Urban Koistinen

Date: 10:06:09 04/08/01

Go up one level in this thread


On April 08, 2001 at 10:26:33, Uri Blass wrote:

>1)I understood that it is the distance to conversion or mate(in the case of my
>diagram it is the distance to mate).
>
>Every position must be in exactly one set that is not dependent in the history
>of the game.

No, every position that is in t0 is also in t2 and those in t2 are also in t4
etc. Same for t1, t3, etc.

>If you include the history of the game then generating 6 piece tablebases seems
>to be impossible task.

No history beyond g50 is needed. Draw by repetition need not be considered.
For each position, only one bit is needed in each table.
There are difference tables also but they are limited to at most 10 bits per
position and I only store those for white to move. Once they have all been
computed they can be merged and stored in at most 6 bits per position.
To do a tablebase with 6 pieces (counting the kings, no pawns) would fit in 18
Gbyte disk space and 320Mbyte core(ram).

>I admit the explanation is not clear but I tried to understand some logical
>explanation and I guess that the author meant:
>g50=0 when there are no half pawn left to the conversion and g50=100 when there
>are 100 quiet moves until the conversion.

You mean half move, not half pawn.
g50 is the number of half moves until the game is drawn by the 50 move rule.

>2)When I think about it again I understand that my explanation is not right.
>
>t1 can include also positions when black is to move and here is an example:
>[D]8/8/8/kQ6/8/8/7R/7K b - - 0 1
>
>It means that t2 can include also positions when white is to move.

No. I have added a clarification the paper.
even: black to move
odd: white to move

Urban Koistinen



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.