Author: Angrim
Date: 11:31:26 04/05/03
Go up one level in this thread
On April 04, 2003 at 17:55:34, Russell Reagan wrote: >On April 04, 2003 at 15:45:49, Angrim wrote: > >>The number of entries in the table is the same, but DTC data compresses >>better, so after compression the tables are smaller. DTC compresses >>better because positions where white can capture usually have a DTC >>value of mate in 1, while with DTM the value is much less predictable. >> >>I seem to recall that for suicide chess, and with my compression method, >>the savings from DTC were around 20-30% smaller files. > >I have often wondered if you could cut the TB's size in half for a little extra Um, rounding to a multiple of 2 doesn't give 50% space savings. It just means that if you needed 8 bits per entry before you now need 7 bits per entry. >computational work when probing. If you stored in your tablebases "codes", you >could extract the meaning of a code with a small search. Currently, when you >probe you get the actual data. Under the "code" scheme, you get back a code >which means something. For instance, let's say that this is our code table: > >0: mate in 0 or mate in 1 >1: mate in 2 or mate in 3 >2: mate in 4 or mate in 5 >3: mate in 6 or mate in 7 >... >254: mate in 508 or mate in 509 >255: mate in 510 or mate in 511 > >If you get back a 1, that means the position probed is either a mate in 2 or 3. >You would have to do a small search to determine exactly which, but that is >trivial, and would only need to be done for outputting purposes. This would lead >to a possible non-optimal move being played, but only off by one, and the result >should still be the same (so you might play a move leading to mate in 10 instead >of mate in 9, no big deal). Maybe things are more complicated in practice than I >am aware of. > >If this does work though, you could get even better space savings than 50%. going from 8 bits per to 6 bits per, or from 5 to 3.. > Your code table could be: > >0: mate in 0 through mate in 3 >1: mate in 4 through mate in 7 >etc... > >As you searched, you would select moves that made progress from one "mate group" >to another, instead of one "mate depth" to another. This idea, generalized as "round to the longest multiple of X" has been suggested before, and has been shown to work. Someone even posted a list of compression savings for X ranging from 2(your first suggestion) to 100(which is usually the same as w/l/d tables) using the nalimov compression method after doing the rounding. I didn't think to save that table, so I don't recall the exact results, maybe the origional poster of that table will read this and repost it. This is not likely to actually be used though, since so much time has already been put into building tables with the current method, and all engines that use nalimov tables would need to change how they probed if the tables stopped returning exact values. If you really wanted, you could do this yourself of course. Just uncompress a nalimov table, scan through it rounding the values, then recompress it and teach your engine how to handle such data. Have fun, Angrim
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.