Author: Dann Corbit
Date: 22:20:38 10/18/01
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.02 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.