Author: Eugene Nalimov
Date: 23:01:10 10/18/01
Go up one level in this thread
(1) Number in the range (0..63) takes 6 bits to naively encode, not 5. So pawnless 5-man TB will use 5*2**30 bits, not 5*2**24. I.e. 32 times larger than your number. (2) Each additional man will increase size of the TB not 5 times, but 2**6, i.e. 64 times. Eugene 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. > >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.