Author: Dieter Buerssner
Date: 16:37:16 11/22/05
Go up one level in this thread
On November 22, 2005 at 12:51:10, Zappa wrote: Anthony, I basically agree. Some minor points >The advantages of bitbases is that they are MUCH smaller. First, many 6-men >tables have DTMs > 127, which means they need two full bytes per position. They would basically need 9 or perhaps 10 bits instead of 8. In practice, with the code of Eugene Nalimove, they use 2 bytes. But those additionial bits are almost free, when compression is used (which is the case almost always). >Bitbases need only 0.25 bytes. My bitbases use 0.20 bytes per position (or less). >Secondly, bitbases compress MUCH better. This >is easy to see, as a tablebase will look like this: > >+11 +9 +25 +4 0 +9 +7 -> mostly wins, but all with different distances > >as compared to a bitbase > >11 11 11 11 01 11 11 -> and all the wins can be compressed very neatly using >run-length/Huffman etc. Furthermore all the wins will tend to lie together if >you order your indexing right. When not done rather smart, bitbases do not compress that much better, than TBs compressed with the routines of Andrew Kadatch. Your argument above sounds very logical. My experience is different, however (and was a surprise to me). I wanted to use bitbases even in the deepest qsearch nodes without any overhead of decompression, caching schemes, ... . Then, compression ratios won't matter anyway. I don't doubt. that in general, compression would help. Regards, Dieter
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.