Author: Robert Henry Durrett
Date: 09:57:39 06/12/02
Go up one level in this thread
On June 12, 2002 at 11:39:31, Robert Hyatt wrote: >On June 11, 2002 at 20:58:37, Robert Henry Durrett wrote: > >>On June 11, 2002 at 18:01:40, Robert Hyatt wrote: >> >>>On June 11, 2002 at 15:56:19, J. Wesley Cleveland wrote: >>> >>>>On June 11, 2002 at 11:52:47, Robert Hyatt wrote: >>>> >>>>>On June 10, 2002 at 18:45:03, Dieter Buerssner wrote: >>>>> >>>>>>I'd like to add, that not for all engines, it is some sort of luck, when they >>>>>>remember past analysis, and when not. I am convinced, that for my engine, it is >>>>>>better in general, to analyze from back to front. I am also convinced, that it >>>>>>will not forget previous analysis. >>>>>> >>>>>>Regards, >>>>>>Dieter >>>>> >>>>> >>>>>It _must_ unless you have a hash table of infinite size... >>>> >>>>If crafty stored the result returned from the prior search in the hash table, >>>>made the age current when the hash table returns a valid score, and started ply >>>>1 with the move in the game, it would always get the most useful value and >>>>nearly always get the very useful values. >>> >>>Crafty does this. Unfortunately _this_ search can overwrite the results from >>>the previous search quite easily. And then you have a problem. Or, in lots of >>>cases, just because the position after the move played at move 29 is found to >>>be bad, when you back up to move 28, you find that the opponent can play a >>>_different_ move at 29 and not wreck the score so you still don't see the >>>"problem" since you didn't search down _both_ paths, just the path actually >>>played in the game. >>> >>>in short, searching from the back to the front leaves huge holes in the tree >>>you pretend to be searching. >>> >>>As I said, I tried this when I first started doing the "annotate" command >>>in Crafty (which was several years ago) because it seemed to be an obvious >>>idea. But after lots of testing with many different people, it became apparent >>>that it caused more questions than it solved problems... >>> >>>At least the current version is consistent in how it behaves, which (for a >>>computer program) is a good thing... >> >>Why not find some sort of compromise? Here's why you might want to: >> >>So far, GM games between the very top human GMs simply produce moves and lines >>which are better than those produced by current chess engines. [I believe this >>to be true.] As long as this remains the case, then it seems prudent to take the >>human GM's moves and lines into account, and give consideration of these higher >>priority in searches. >> >>In other words, if asking the chess engine to do a post-mortem ["overnight"] >>analysis of such a game, you would want to closely examine the human GM ideas >>expressed in that game. >> >>Bob D. > > >First, the "annotate" facility in crafty _does_ follow the actual game. > >But as to "giving priority to the GM moves/lines" I don't know how to do >that within alpha/beta. The evaluation of a program (Crafty in this case) >guides the search regardless of the moves actually played in the game being >examined... I am not one to talk, since I could never do it. But still: Innovation a la Thomas Edison [software version] might do it
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.