Author: Robert Hyatt
Date: 12:34:54 11/23/01
Go up one level in this thread
On November 23, 2001 at 14:18:27, Uri Blass wrote:
>On November 23, 2001 at 10:52:58, Robert Hyatt wrote:
>
>>On November 22, 2001 at 23:16:41, Dave Gomboc 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". You don't find the
>>>>_real_ place where you screwed up (a), instead the score seems to drop at
>>>>(b) which is the wrong place.
>>>>
>>>>Since neither way finds the actual mistake, I don't like the back-to-front
>>>>approach because if you do search front to back you will find the "mistake"
>>>>at a different place, which is nothing more than confusing.
>>>
>>>Overall, the analysis is more accurate when it is performed from back to front.
>>>Sure, there are still mistakes, but that's life.
>>>
>>>You used to recommend the back-to-front order yourself. In fact, I remember you
>>>criticising Fritz once for doing it in the forward direction. :-)
>>>
>>>Dave
>>
>>
>>I don't remember critizing Fritz, but whether I did or not, I decided to try
>>it and didn't like it. I want the program to be as consistent as possible when
>>it gives me analysis. If it can _prove_ that my move was worse then I want it
>>to say so. But if it can't, I don't want it to say so just because it luckily
>>kept something critical in the hash.
>>
>>IE if the _real_ problem is at move (A) and the program can't see it is in
>>trouble until move (B), then Crafty will report the problem at B every time,
>>until the hardware gets faster and then it will report it at B-1, etc...
>>
>>With the reverse annotation idea, it will report it at random locations between
>>(b) and (a) which I simply didn't like. Change the hash size (bigger or
>>smaller) and the point where it spots the problem changes.
>
>Between b and a is better than b because you have a better upper bound for the
>move that you made your mistake and if you go to do long analysis with Crafty to
>discover the mistake you can at least avoid analyzing some moves after the
>random location.
>
>There are also cases when it can see the real problem by going backward.
>Nothing is perfect but going backward is better than going forward.
>
>Uri
All I can say is that "better" is an opinion here. I prefer consistent
behavior over all else, otherwise debugging is impossible.
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.