Author: Ronald de Man
Date: 05:16:57 12/18/05
Go up one level in this thread
On December 16, 2005 at 00:11:28, Robert Hyatt wrote: >On December 14, 2005 at 19:25:38, Dann Corbit wrote: > >>On December 14, 2005 at 19:18:28, Uri Blass wrote: >> >>>On December 14, 2005 at 18:53:21, Dann Corbit wrote: >>> >>>>What's the other way to do it? >>> >>>see my post in >>> >>>http://www.talkchess.com/forums/1/message.html?470096 >> >>Can't the same position (therefore) have a huge number of different scores then >>(depending on where we saw it in the tree)? >> >>Tbis way seems more complicated to me. > > >It is. The obvious solution is when you store a mate score, it must be mate in >N from the current position depth, not the root, not from the start of the game. > Otherwise you will get _really_ confusing mate scores from hash. Indeed. For a moment I liked this other way, but Dann's observation is correct. I don't see how one can make it work correctly. Think of a mate position that can be reached from the root in 5 plies, but can still be delayed for 4 more plies. Then it's a forced mate in 9 plies (mate in 5), but the search might report 5 plies (mate in 3). You can also have the opposite case: a mate position that is first found by the search (and stored in hash) at the end of a long series of checks, but can actually be reached in far fewer plies. In this case the search would report a number of moves to mate that is too high. I don't see how this could be solved by storing the mate score as an upper or lower bound instead of an exact score. There's no guarantee to have either an upper bound or a lower bound, as far as I can see. Storing the number of plies to mate counted from the start position indeed solves the problem of aging hash entries, but it creates problems as well.
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.