Author: Angrim
Date: 18:11:25 01/30/02
Go up one level in this thread
On January 30, 2002 at 20:43:44, Dann Corbit wrote: >On January 30, 2002 at 20:37:27, Angrim wrote: >[snip] >>I wish you would stop posting this over and over. In this and quite >>a few other posts you have stated that this method would be a huge >>improvement over current tablebase formats, while clearly not >>understanding current tablebase formats. >> >>quick summary of the state of the art in tablebase storeage: >>1. all safe symetries are used to reduce the number of positions. >> for tables with pawns, this is left/right and side to move. >> for tables without pawns this also includes top/bottom and diagonal. >>1a. positions in which the two kings are touching are also excluded. >>2. each position is stored as a combination of filename(KBvkr or such) >> and an index into the file, no bytes are used to store the position. >> At the index into the file coresponding to a unique position, the >> value for that position is stored. >>3. the resulting table is then split into 8k blocks, and compressed with >> a block compression algorithm optimized for decompression speed. >> >>The resulting compression for pawnless tables is roughly: >> 20x reduction in number of positions from the symetries and avoiding >> illegal positions. >> 6x compression from the block compressor >> so 120 position's values stored per byte of tablebase file. >>for tables with pawns, it is: >> a little over 4x from the symetries and avoiding illegal positions. >> 6x compression from the block compressor >> so 24+ position's values stored per byte of tablebase file. >>And note that these are averages for all 5pc endgames, not just the >>best case situation with only sliding pieces. > >Yes. Thank you for this nice summary. Of course, every one of these techniques >can be used for the new format, but we throw out all positions which are already >covered by a sliding piece rule. You imagine that there is no reduction from >that? > >Someone has stated that there will be no reduction. That is not true. Hmm, this made me stop and think a bit. If you could actually skip over the positions that are covered by your rule, while still using the current index based methods, the resulting savings would indeed be nice. However, I do not see any way to do this. To calculate a positions index, you need to know how many positions that would otherwise have been in this file would have been before it in the file. For the "kings not touching" rule, this can be calculated directly based on the positions of the two kings. If there is a way to calculate this for the sliding piece rule, I have overlooked it. If you do come up with a practical way to do this, it could make this whole thread worthwhile :) Angrim
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.