Author: Les Fernandez
Date: 09:05:43 11/13/01
Go up one level in this thread
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?? 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.