Author: Tony Werten
Date: 03:11:28 10/20/01
Go up one level in this thread
On October 19, 2001 at 22:16:46, Bob Green wrote: >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. Sorry. If x or y equals pawn then you're not allowed to rotate that way. Tony > >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.