Author: Robert Hyatt
Date: 21:59:15 11/23/01
Go up one level in this thread
On November 23, 2001 at 14:03:37, J. Wesley Cleveland wrote:
>On November 22, 2001 at 19:52:04, Robert Hyatt wrote:
>
>>On November 22, 2001 at 15:09:56, J. Wesley Cleveland wrote:
>>
>>>On November 22, 2001 at 09:42:36, Robert Hyatt wrote:
>>>
>>>>On November 22, 2001 at 05:27:05, Gordon Rattray wrote:
>>>>
>>>>>The Fritz GUI analyses games ("Full Analysis") by starting at the end of the
>>>>>game and retracting moves. How does this compare to going forwards? Does it
>>>>>produce better results?
>>>>>
>>>>>I think this issue has been discussed before, but my search has failed to find
>>>>>anything. Please feel free to forward me a past link if appropriate.
>>>>>
>>>>>Gordon
>>>>
>>>>
>>>>Here is the idea...
>>>>
>>>>If you start at the end of the game, you load the hash table with stuff
>>>>that will help as you search at earlier moves... with the "idea" that
>>>>earlier analysis will be more accurate since it will have access to these
>>>>scores.
>>>>
>>>>It doesn't work however.
>>>>
>>>>IE pick three points in the game, (a) where a key mistake is made, (b) a
>>>>position further into the game, and (c) a position near the end where the
>>>>program can see that it is lost. As you search backward, when you reach
>>>>(b) the search might well _still_ see that it is lost, because of the persistent
>>>>hash entries that help. But when you back up past (b) eventually the
>>>>hash entries get replaced, and you "lose the key scores".
>>>
>>>This sounds like a bug (or missing feature) in the replacement algorithm. We are
>>>only talking about tens of positions (those that actually occurred) and they
>>>should be somehow marked so that they stay in the hash table. Even the nodes
>>>below these should have been analyzed to enough depth that they should almost
>>>certainly remain in the hash table.
>>
>>
>>No... stop and think about this for a minute. If you could only store 10 or
>>20 positions, we could solve chess. Storing the score for move (say) 30 for
>>white only makes black want to play something different the move before.
>
>But this is all we are looking for. If we find a move where where (say) black
>has an alternative that is significantly better than the move made, we have
>found our mistake. It may be that this move is also bad, but too deep for the
>computer, but this means we need to analyze longer, not in a different
>direction.
You haven't thought about the _tree_ yet. If you store a single position
from move 30, and then start a search from (say) move 25, do you think that
_one_ score will affect the search for move 25? It won't. And that is the
problem. One position at the tip of the tree won't necessarily influence
the move N plies back at the root, due to the sheer size of the tree itself.
This is why an occasional hash collision can't be detected by looking for
score changes. Takes too many tip scores to change the score of a N ply
search back to the root...
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.