Author: Robert Hyatt
Date: 21:24:08 10/21/01
Go up one level in this thread
On October 21, 2001 at 20:59:30, Ratko V Tomic wrote: >Dan: >>>I don't know why you need to know the distance to mate (which is given >>> as the reason not to store the move). If you make the best >>> possible move, then it does not matter what the distance is. > >>If you only use N piece tablebases once you are down to N pieces on >>the board, then your idea would work. However you also need to be >>able to probe them when you reach an N piece position in the search, >>and want to find out if this position is won or lost. For this purpose >>all you need is win/draw/loss, and some people do use tablebases that >>only store this information since they take less space. But to find >>the shortest win when searching a position with more than N pieces, >>you need to have distance to mate stored in the table. > >Dan was talking about keeping the best move (instead of distance to >mate), not the win/draw/loss only. Knowing the best move implies >the knowledge of the distance to mate since the child nodes >of a table position are also table positions i.e. one can follow >the best moves and obtain quickly the distance to mate. So, here >one would trade off potentially large quantities of table space >for some additional time cost in extracting the distance-to-mate >value from the best-move value. > >Since the best-move encoding can take advantage of any endgame >knowledge one can put into the move generator (used to list the >available moves and specify the best one), this approach allows >potentially large space savings which is further improvable as >the more knowledge gets added to the encoder (using arithmetic >encoding and a good quality generator, one may encode the best >move in a fraction of a single bit, at least for those clasess >of endgame positions where the generator can offer the best >move with a probability greater than 50%). The direct distance >to mate encoding doesn't offer any obvious way to save space >by adding endgame knowledge into the encoder. Here is the problem you have to solve: 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???
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.