Author: Robert Hyatt
Date: 20:29:00 10/22/01
Go up one level in this thread
On October 22, 2001 at 22:35:43, Ratko V Tomic wrote: >>When searching and you hit the tablebase deep in the tree, all you get >>is the "best move" for that position. How do you differentiate between >>the _thousands_ of tablebase hits you get to choose the shortest mate? >>The engine has to choose between multiple paths that lead to tablebase >>positions. How does it choose _which_ path to follow??? > >You would follow up the "best-move" for each side until you >either find cached distance-to-mate value or reach the >mate/draw (which you could save for later searches). The >distance-to-mate is implicit in the best-move table, it just >takes a bit of calculation (as do Huffman or other decoding >from compressed tables or, for that matter, any leaf node evaluator). > That was my point. A normal EGTB hit is the end of the work. This will require another 100 EGTB reads if it is a mate in 50. That would absolutely crush performance and weaken the program to the point it would be far stronger without the EGTB's that have to be used like that. >So, indeed this does trade off some time for space, since the >best-move, while needing iteration to obtain the position value, >it can benefit cummulatively from any endgame knowledge/rules one >can extract from human endgame theory or via computer based >pattern/dictionary extractor (done, of course, during the >contruction of such tables, not during the play). > >Distance-to-mate has no simple relation to patterns in positions >(since it is a result of multistep iterations over highly nonlinear >functions), while the best-move has more local nature, immediately >related to the position at hand and its patterns. > >A good analogy would be billiards, where distance-to-mate gives you >final outcome after large number of collisions, while the best-move >tells you how to aim the shot given the layout of the balls. While >the former is closer to what one may wish ultimately to know, the >latter is closer to what you have in front of you, thus it is closer >related to the patterns of the existent layout (therefore it can >compress better). > >Additionally, for conventional chess, the "best-move" need not be the >shortest distance to mate, since a point is a point, however many >moves it takes you to win it (after all computers don't tire out; for >human player it may matter how quickly they can finish off the opponent >if they need to play next game hours later). > >Thus, if the move generator used by the best-move decoder can produce >with high probability move which wins (or holds draw) with certainty, >as far as program's rating/"strength" is concerned, it doesn't matter >that the move isn't the fastest way to mate. The program will benefit >more from resulting space saving, due to the wider range of endgames >accessible (and may still end up faster since additional memory >paging costs probably much more than the iterations I suggested). > >The exact distance-to-mate can serve as a valid leaf value only >for reasarch on endgames, combinatorics, game theory, etc. But >it doesn't map directly (or exclusively) into program's >rating/strength in the conventional chess.
This page took 0.01 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.