Author: Ratko V Tomic
Date: 21:12:28 10/20/01
Go up one level in this thread
> Whatever the case, you need to make the best possible move > and if that has been encoded, it seems like it should > be enough. If you have the best move, you automatically have the distance from mate (if available), since you can iterate the best move for each side until a draw or a mate occurs. This iteration should take negligable amount of time (if program actually needs to display such result or decide whether to accept a draw; otherwise for merely playing games, it is enough to know the best move, so the iteration takes no time). In turn, the best move, provided one uses a move generator with some smarts built in (so that the estimated best moves are generated near the front of the list), would use on average fewer bits than a dumb move generator (and much less than from-to type encoding). If for some piece set the best move needs B bits on average, and if you're using hash table index of H bits (e.g. hash table with 65536 buckets has H=16) and if each position takes P bits to distinguish itself from all others for that piece set (after reduction for all symmetries), then one can encode the whole table in P-H+B bits per position (by sorting the positions on hash value and keeping only the count of positions for each hash value; this count table adds (2^H)*P/2^P bits per position, i.e. a small fraction of a bit for properly selected H; the special case H=P, i.e. when position encoding is used as the address into the table, doesn't have this hash table overhead since the count in each buceket is always 1).
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.