Author: Ratko V Tomic
Date: 15:09:50 10/23/01
Go up one level in this thread
>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. >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.