Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: New BIT squishy idea

Author: Tony Werten

Date: 10:10:51 11/13/01

Go up one level in this thread


On November 13, 2001 at 12:05:43, Les Fernandez wrote:

>On November 13, 2001 at 10:09:30, Robert Hyatt wrote:
>
>Hi Bob,
>
>I am in the process of working on a different way of storing egtb's.  Keep in
>mind that the method I am playing with allows me to store ie 28 chess board
>positions, side to move , ce and pv in 50 bits (50/28=1.8 bits/position before
>any form of compression).  The method I am researching guarantees that the pv is
>no worse then what would be  reported from an egtb search but I can not
>guarantee that the pv leading to mate is the minimal move.  As long as we know
>the mate information, even though it may not be the most minimal, can still be
>considered useful information.  Although this type of information may be found
>to be useful, from a theoretical interest in the study of endgames I am still
>counting on Eugenes tables.  The consequence to this method may be performance
>with speed but conceptually it appears to be sound.
>
>BTW any idea with max compression what can be done with 1.8 bits??

Hard to say. Depends very heavy on the percentage of bits set and the
regularity.

Tony

>
>Les
>
>
>>On November 13, 2001 at 08:31:09, William Penn wrote:
>>
>>>I suspect this has been discussed before but I didn't pay attention, so please
>>>pardon my redundancy. If you could just point me in the right direction, much
>>>appreciated...
>>>
>>>Can't we make some assumptions without compromising very much practical playing
>>>strength and significantly reduce the size of the endgame tablebases? For
>>>example it seems a waste to generate separate positions for "white to move" and
>>>"black to move".
>>
>>How would you handle all the common zugzwang positions?  black king at e6,
>>white king at e4, white pawn at e3.  White to move draws.  Black to move
>>loses.
>>
>>
>>> Surely there is a reasonable simplification in that regard
>>>based on symmetry. Promotion of a pawn to less than a Queen is rare and could be
>>>disregarded.
>>
>>There are plenty of positions where underpromotion is the only way to avoid a
>>stalemate.  That would convert many wins into draws.
>>
>>
>>
>>> Perhaps castling can be disregarded because it seldom happens in
>>>the endgame.
>>
>>castling is already ignored and not part of the tables.
>>
>>
>>> I suppose we must keep en passant(?). I'm guessing that the size
>>>could be reduced to perhaps only 1GB for all of the 3-4-5 piece positions vs the
>>>current 7GB. That would also make it more practical to generate 6-piece
>>>positions. Anybody know how?
>>>WP
>>
>>
>>eliminating 1/2 the tables cuts it to 3.75 gigs.  None of the other changes
>>you suggest are doable.  And eliminating either wtm or btm will cause problems
>>as I mentioned.
>>
>>7.5 gigs is a trivial amount of disk space today, with new machines usually
>>coming with at least a 60 gig drive.



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.