Author: David Eppstein
Date: 00:06:47 10/10/98
Go up one level in this thread
On October 10, 1998 at 00:56:05, blass uri wrote: >You need memory to store the best move for example in KBBKN for the stronger >side the maximal number of legal moves is 8+13+13=34 legal moves >and you need 6 bits for a move so I think you do not save memory by this. >If you have a good order of moves and always 1 of the first 32 moves is best you >can need only 5 bits > >If you store distance to conversion with my idea you need only 5 bits >for 1-2,3-4,...49-50,draw,loss >You need to do a search but I do not think there is a problem with small search. If you do compression and on-the-fly decompression of blocks of your tablebase (the way to go I think for getting the total size down; compress blocks rather than whole file at once so you can quickly decompress only the pages you use) then what you should be striving for in setting up the uncompressed form of your tablebase is not the fewest bits but most compressible patterns. Compression is based on prediction: something is compressible exactly when it is predictable. So, for instance, win-loss-draw information in a tablebase like KQKR is very easy to compress (easy to predict: it's mostly just wins) but distance-to-mate is harder (the messiness of these numbers is related to the difficulty of playing the endgame without a tablebase). Your proposal saves a small percentage of total bits in the uncompressed file while making the distance numbers even messier. My guess is that Roberto's suggestion of storing a database of best moves, rather than of distances, is a big win in this respect. We already have a pretty good idea how to predict best moves (just do a shallow search based on any reasonable evaluation) so they should compress well.
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.