Computer Chess Club Archives


Search

Terms

Messages

Subject: Distance-to-mate vs Best-move tables

Author: Ratko V Tomic

Date: 19:35:43 10/22/01

Go up one level in this thread


>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).

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.