Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: EGTB: Better algorithm

Author: Vincent Diepeveen

Date: 13:13:05 04/08/01

Go up one level in this thread


On April 08, 2001 at 06:47:56, Aaron Tay wrote:

>On April 08, 2001 at 06:14:44, José Carlos wrote:
>
>>On April 07, 2001 at 11:18:34, Urban Koistinen wrote:
>>
>>>I have written down a algorithm for computing endgame tablebases that should be
>>>about 10 times quicker than the Nalimov algorithm and requires much less ram.
>>>It is similar to the Arlazarov&Futer algorithm of 1979 but is more general as it
>>>does not require a pawn.
>>>It might be too technical for most here,
>>
>>  Thank you. Too technical algorithms are not for a crowded-of-programmers forum like this. We wouldn't understand anything.
>>
>>  José C.
>
>Hey , be nice. He's new here.
>
>He is just feeling a little fustrated after posting at r.g.c.c and getting only
>one response. Knowing the high level of general technicial expertise here, I
>suggested to him  that he should post here.
>
>So what do the experts think? Is the algorithim as good as he claims? Layman
>like me want to know!

Yes the algorithm is good, but the math below is not correct.
A harddisk is not doing 40mbit/s when doing random lookups.

Also the algorithm is very cpu intensive when you try to get the EGTBs
smaller as 4096 * n where n is the position without the 2 kings at the
end.

The big problem is that you need 4096 positions for the king
as otherwise the conversion from white to move to
black to move is going to use too much CPU time.

Anyway the programming is very hard. I'm using this already for years
though. a 5 man goes real fast as it is all fitting within the memory
ram. About an hour.

I don't get the discussion about whether a position is mate in 20 or 23.
I don't care personally whether a position is mate in 20 or 23.

If i can get an egtb hit from a 6 man with just win/draw/loss/win50+/loss50+,
then that's excellent i think. The alternative is NOT using a 6 man,
as Nalimov is not going to generate 6 men with pawns real quick.

This algorithm provides a basis for computing things way quicker.

The BIG drawback of this algorithm is that you need 4096 positions for king,
because that's a huge increase in storage space when generating.
Actually the biggest increase is the I/O needed and with such huge
tables you DEFINITELY don't want Random I/O. If you solve that problem,
then you need loads of RAM to generate 6 men with pawn with this algorithm,
and that's a big problem as the ram needed is even bigger because the
table size is that big as you need at the end 2 kings.

So yes the algorithm works. But no it's not 64 times faster, but if
the problem is random i/o, then this is not going to help you much
as the random i/o only gets more than doubled.











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.