Author: Miguel A. Ballicora
Date: 00:31:22 07/13/03
Go up one level in this thread
On July 12, 2003 at 19:39:42, Omid David Tabibi wrote: >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... You had a bug in your debugging code and you found it. You did not waste time IMHO. >>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... I do not see that a debug test is stupid at all. Even if it looks silly. At least, it always help you to understand the logic of the program and detect when that logic is no longer valid. Miguel >> >>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.