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.