Author: Tony Werten
Date: 11:24:37 10/19/01
Go up one level in this thread
On October 19, 2001 at 01:20:38, Dann Corbit wrote: >For pawnless and rookless tablebase files: > >The name of the file tells the pieces (e.g. KBBKQ) >Side-to-move King, Bishop, Bishop >Side-not-to-move King, Queen >No bits needed to encode this data. > >Then, 5 bits for the positions of the pieces (0-63) times the 5 pieces = 25 bits > >This is the key (the above 25 bits). >So for any tablebase of this format, there are 2^25 entries. > >The answer is encoded as follows: >Then the move to make (which we can encode in 8 bits -- the move number from 0 >to 255 considering the moves as sorted lexically or as output by a specific move >generator.) > >Then we need status: >Won/Loss/Drawn/Broken -- > 4 states means 2 bits. > >That is 12 bits. So any pawnless/rookless tablebase file will need a total of: >12*(2^25) = 402653184 bits = 50,331,648 bytes before compression. > >How does this compare with a decompressed 5 piece Nalimov tablebase file? > >For positions with rooks or pawns, we could just use a format like the current >one. > >Seems like it might be a real big win for 6,7,8 man tablebase files. Each file >will be exactly 5 times larger than the file one generation before it before >compression. Even if the files were 50Mb (wich they aren't as others explained) then still the number of possible piececonfigurations would make 7 and 8 men tbs quite large ( in total ) (If I calculate correct, 6 men would still take 200 Gb, seven would still be a couple of Tb or even Eb ) Tony > >So a 6 man tablebase file would take 250 megs before compression. >And a 7 man tablebase file would take 1250 megs before compression. >etc. > >Is my brain the cause of pain because the notion is insane?
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.