Author: Omid David Tabibi
Date: 16:39:42 07/12/03
Go up one level in this thread
On July 12, 2003 at 18:52:18, Ed Schröder wrote: >On July 12, 2003 at 18:10:39, Omid David Tabibi wrote: > >>On July 12, 2003 at 15:06:55, Dieter Buerssner wrote: >> >>>On July 12, 2003 at 14:43:52, Heiner Marxen wrote: >>> >>>>On July 12, 2003 at 14:13:25, Omid David Tabibi wrote: >>>> >>>>>Hi, >>>>> >>>>>After a few days of rewriting large parts of my program's code, to my surprise I >>>>>found out that: >>>>> >>>>>if (value >= beta) >>>>> return beta; >>>> >>>>The classic version. >>>> >>>>>and >>>>> >>>>>if (value >= beta) >>>>> return value; >>>> >>>>This variant is called "fail soft". >>> >>>When also additionally, you don't return alpha in fail low situations, but a >>>best value. I actually wonder, if you have a classic fail hard search, and just >>>change one line in search like above, can it change anything? The parent node >>>could return alpha (not less). So did the child. Where can this value > beta >>>come from? >>> >>>>The caller must be prepared to receive a value outside the alpha/beta window. >>>> >>>>>don't yield the very same result. >>>> >>>>The second version (fail soft) has the potential to generate better results, >>>>sometimes. When these are reused via the TT, the rest may change. >>> >>>Yes. It might also influence move-ordering, for example when using some "mate >>>killer heuristics". Additionally, for PVS combined with null move an aritifact >>>can arise. With another bound in the research (which will be needed here), you >>>might not fail high null move anymore (the original null move fail high was sort >>>of bogus), and the whole normal search could show, that it would not result in a >>>value as high as the value returned by the null move. Similar for other pruning >>>techniques, and perhaps even extensions (when dependent on bounds). >>> >>>>>I've been trying to find the bug for the past 24 hours, without any success so >>>>>far. Has anyone experienced this problem in the past?! Any ideas as to the >>>>>possible source of the problem? >>>>> >>>>>Thanks. >>>> >>>>What is the problem? >>> >>>Good question. Many such things are just unavoidable for efficient search. >>> >> >>But when transposition table, PVS, apsiration window, and null-move are all >>turned off (for the purpose of debugging) then fail-soft and fail-hard should >>result in the same tree (same node count), shouldn't they? > >Hint, > >Check all your initialization stuff before the search starts, zero everything >for reproducable number of nodes. For instance, if there are still killer moves >from the previous search present this will effect the next search, and so on. > Oh, well, I found the "bug". It was far more stupid that I imagined: when I disabled PVS for debugging, it wasn't completely disabled, so the difference in node count was natural... It is soooo frustrating to find out that you have wasted a whole day for a nonexistent bug... >It doesn't sound to me you have a bug, fail soft is okay, I never have used >otherwise. Yes, I also use fail soft, which results in more transposition table cutoffs. But from time to time I do some tests (compare it with fail hard) to make sure everything is ok. Once this method helped me detect a nasty bug, but I think I have to stop doing such stupid tests... > >My best, > >Ed
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.