Author: Bob Green
Date: 19:16:19 10/19/01
Go up one level in this thread
On October 19, 2001 at 01:20:38, Dann Corbit wrote: Okay, time for my brain fart.. For games K1xxK2y (where x=p/b/n/r/q, y=p/b/n/r/q). Side-to-move K1xx, side not-to-move K2y. Rotate board to get K2 (side not to move king) in upper left quadrant upper diagonal. Location of all 5 pieces can be in 6 bits if irregardless to type. Using the ordinal (counting) position in the 6 bits can be found in 3 bits (i.e. if the K2 is the 3rd bit set, etc.) 3 bits for K2, 3 bits for K1 and 3 bits for y. 6+3+3+3=15 bits. This is the key to the tablebase. There are 2^15 entries. (note: this key needs to be expanded by 3 bits for K1xxK2yy, this key works as is for Kx...K2y) The value of the entry is: 1 bits won/loss (don't do brokens) 2 bits for the ordinal position of the piece moving+1, 0 for draw 4 bits for the ordinal move number from the move generator for _the piece moving_ Therefore this tablebase size before compression is: 7 * (2^15) (o) <-- target for brickbats... Bob Green >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.