Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: EGTB: Better algorithm

Author: Vincent Diepeveen

Date: 13:19:41 04/08/01

Go up one level in this thread


On April 08, 2001 at 13:06:09, Urban Koistinen wrote:

Urban,

First let's be clear on your algoritm that it's a brilliant algorithm
to save CPU time. CPU time gets reduced 64 times when one would use
the same indexing scheme.

But the only interesting thing in chess when talking about EGTBs
are 6 men WITH pawns.

One sees now and then in computerchess a 6 men pawnless endgame, but that
only happens when both programs play incredible stupid somewhere, so there
was already a lot to improve in the engines then.

In a good game one should never need pawnless 6 men. However the number
of 6 men with a pawn which would influence the outcome of the game
when one would have win/draw/loss information about it, that is
real huge.

With 6 men with pawns the computers would really get smart in far endgame!

All my calculations about 6 men i always take into account 6 men WITH pawns.
That one can generate KRBKBN real fast is out of the question already
for years for me. Even at a 486 with quite some RAM
you can do that easily if you get rid of illegal positions a bit!

Best Regards,
Vincent





>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.