Author: Les Fernandez
Date: 11:15:57 11/13/01
Go up one level in this thread
On November 13, 2001 at 13:41:39, Rafael Andrist wrote: >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?? >> >>Les > >What informations do you want to store in 1.8 bits per position? If you only >store win/draw/loss, you should come close to lb(3) = 1.58496... >E.g. in 64 bits, 40 positions are possible, with only 1.6 bit/pos. I am interested in storing chess positions that contain up to 8 pieces. I am storing the board positions, side to move, pv and ce. Keep in mind that this method is not to displace Eugenes tb's but a method which minimizes chess positions that lead to mate using as little space as possible. > >Rafael B. Andrist
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.