Author: Robert Hyatt
Date: 15:25:15 10/23/01
Go up one level in this thread
On October 23, 2001 at 18:09:50, Ratko V Tomic wrote: >>1 bit per position value, your savings are not that good. The >>current tablebase method takes around 1.3 bits per position >>after compression. > >Is the 1.3 bit/position valid only for archiving database >on disk, or is it a working size (used directly during >search)? I.e. to lookup the data in the search tree, does >one have to expand the blocks of tables? If it does need >block level expansion, then that refutes the Bob's 1-lookup >per leaf node assertion, since if you need to decompress >entire block with thousands of distance-to-mate values >for one lookup, that's no different than having to follow >up a sequence of say 100 best moves. You have to read in some "blocksize" anyway. Our blocksize is 8K bytes. But that is one I/O to get the byte I want. I don't have to read in 99 _more_ blocks to track down to the mate-in-N score... > >>Totally wrong. DTM tables actually have a quite high level >>of predictable patterns, the most common ones being that positions >>whose indexes differ by 1, 8, or 64 tend to have the same value. >>This is because these positions differ only by one piece being >>located one square away. These predictable patters provide a >>significant boost to the compression rate as compared to >>huffman by itself. > >These are relatively crude patterns in the same category of >pattern as the simple board symmetries (all of these I assumed >already factored in, i..e they're available equally to any >encoding method). > >The patterns I was talking about (that the best-move tables can >use for compression, but not the distance tables) are the >nontrivial endgame rules/knowledge built into its move >generator. If you imagine a program posessing the patterns >you're mentioning (in addition to the bare legal move generator), >it would, for all practical purposes play random chess, weaker >than a human novice ten minutes after learning how the pieces >move and what is the objective. This is in a different legaue >compared to even a simple move generator which knows only the >plain captures in the next move, to say nothing about a generator >which knows various quick-to-compute endgame rules. All such >patterns are far outside the reach of distance-to-mate table >methods for reasons mentioned earlier. > >Note also that the strength (rating/points) are not strictly >correlated to the shortest mate but to the ratio of points won >to the points lost. In other words, you pay in large overhead >with distance-to-mate tables for knowledge which doesn't >contribute to the strength of the program (however >interesting it may otherwise be in some endgame reasearch).
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.