Author: Ratko V Tomic
Date: 08:01:40 10/23/01
Go up one level in this thread
>I don't see how. I will never probe them most likely. > Because once I get a TB "hit" I don't search down that > branch any further, period. Well, not in that evaluation. But in the hundreds of millions of evaluations with a limited number of pieces (which may have few hundred millions distinct arrangements all together) the odds of hitting the "wasted" piece arrangement later are certainly much greater than the odds of hash table hits in the middle game. Your cutoff argument would equally imply that the middle-game hash tables are useless. The point is that you can arrive to the same position may different ways, especially for the kind of material on the board the tablebases cover. Note also that fetching a chunk of table from the disk, to perform what seems to program "one lookup," via file read or the "transparent" memory paging by the OS, will take more time than few hundreds simple RAM/CPU based calculations to deduce the same value. That's why compressed disks work often faster than uncompressed -- a single extra wait of few milliseconds for a disk spin to fetch a page pays for millions of computation steps of the decoder, which in turn covers much greater quantity of data than the page being fetched. >>Considering also that using the best-move you may be able to >>fit couple times more table information on any given disk >>or RAM size you have available, > > All the TBs so far use 8 bit values. So there is no savings > on the "best move" approach until we get to the 6 piece files > with mates > 127... Well, no saving if you encode the best move in a byte. With the right pattern preprocessor/dictionary extractor and move generator the best move ought to fit on average in 1 bit or less. The best move table can easily take advantage of any endgame rules or knowledge, human or computer extracted patterns, to make the move generator produce the best-move in many fewer tries than a random move generator would do (which is the most of a pattern that Huffman or similar memoryless stream compression could squeeze out). With distance-to-mate tables the only compression available is of that 'memoryless stream' type, since the values in these tables are result of multi-step iterations of highly nonlinear functions, so for all practical purposes any simple connection to the patterns in the initial positions is lost by the time you reach the terminal node and get the distance value. The only regularity left which is readily extractable are the bulk frequencies of different distance values. The rest of pattern is oblitareted. The best-move tables are more similar to gradient methods of optimization which are sensitive to the local patterns. The move generator used in the best-move table decoder can easily and beneficially (for compression ratio) absorb any amount of knowledge/regularity in data one can come up with.
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.