Author: blass uri
Date: 02:06:20 10/10/98
Go up one level in this thread
On October 10, 1998 at 03:06:47, David Eppstein wrote: >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. I agree. If we have a good evaluation function then we can compress the best move by not more than 3 bits(if I suppose that 1 of the 8 best moves by evaluation is realy the best move). so even if the result is not predictable it may be a good idea to compress by storing the best move and the result and not storing the number of moves to mate divided by 2. Uri
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.