Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Question about Bit storage

Author: Dann Corbit

Date: 13:58:56 01/29/02

Go up one level in this thread


On January 29, 2002 at 16:31:06, Andrew Dados wrote:

>On January 29, 2002 at 14:35:56, Dann Corbit wrote:
>
>>On January 29, 2002 at 14:11:47, Uri Blass wrote:
>>[snip]
>>>>No.  His notion is that if you mirror using every symmetry, the total number of
>>>>those positions (including ALL reflections) would be less than 2^81 in that
>>>>category.
>>>
>>>If this is his point then he is wrong.
>>>
>>>The number of reflection of the same position is only 4 so the total number of
>>>classes of 4 positions is only 1/4 of the number of positions and it cannot be
>>>less than 2^81.
>>
>>I was unclear.  You should read his document.  It also included all motions of
>>the sliding piece to the winning position.  Be aware that this system does not
>>produce a sure best move.  It could be thought of as producing a winning bound.
>>
>>If you look at the list of positions Les posted, all 44 of them were generated
>>by a single position.  I suppose if you read the document:
>>ftp://cap.connx.com/pub/les/cp.doc
>>it will be immediately clear to you.
>>
>>It could also be used to produce alpha/beta bounds for moves that are analyzed.
>>Again, it might not produce the best possible move.  But it could produce a
>>bound that you know it cannot be worse than that.  So, in a sense, it could also
>>be used to create an inexact information database for move choices.
>>
>>You would get similar compressions for arbitrary positions at the beginning of a
>>game.
>
>For pawnless endgames with Rooks, Queens or Bisops it is an attractive idea. For
>pawn only endgames I don't see much gain if any.
>
>How would you store/retrieve from such a database efficiently? Some sparse
>arrays? String collection? Any SQL would kill you performancewise.

An in-memory skiplist (thinking ahead to the time (a couple years from now) when
a gigabyte of ram is $50.

Or a database with a unique, clustered, 64 bit hash index.
To calculate these keys in the fly is fast even in VB.

I propose using the keys only on the root node, if the data is too expensive to
look up.  Even if it took a full second, it would provide value unless someone
stooped to the evil game of lightning chess.  If they play lightning, then we
turn them off, and let the user suffer the consequences.  Perhaps there is also
a way to electrify the keyboard.

"It will take too much space" always goes away eventually.  The full seven man
tablebase file set will fit nicely on a PC in a few years.



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.