Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: AlphaBeta has a bug.

Author: Bas Hamstra

Date: 14:40:07 08/25/99

Go up one level in this thread


I confirm I couldn't reproduce it without nullmove. Hashing on or off doesn't
matter. My hashcode is perfect :)

Well, remains the fact that a small aspiration window sometimes strangely
interacts with nullmove and fails to produce a value within a window when there
*is* such a value that can be found with a wider window.

And I am not yet convinced that this cannot happen without nullmove. Simply
because the Eval >= Beta trick is imperfect. With a small window it cuts off
many combinations in the qsearch, that with a wider window it wouldn't. So how
can I be sure a smaller window leads to the same score as a wider, even without
nullmove? Assuming true score within window? Theoretically it could fail to see
winning combinations by cutting of *winning* capture-sequences which would not
happen with a wider window. And thus return a different score. Can you please
explain why that is impossible?


Regards,
Bas Hamstra.











On August 25, 1999 at 16:46:04, Robert Hyatt wrote:

>On August 25, 1999 at 15:27:43, Bas Hamstra wrote:
>
>>Oops: forgot to tell recursive nullmove was ON. Will test without too.
>>
>>On August 25, 1999 at 15:19:00, Bas Hamstra wrote:
>>
>>>Well at least the popular ab approaches have a bug.
>
>the trick with eval > beta is not alpha/beta.  That is a programmer's
>trick. However, if you are at a leaf/tip position, that is perfectly
>correct...  because with traditional alpha/beta scores can't get > beta
>or less than alpha.
>
>If you turn off null move, and turn off hashing, you won't see _any_ of
>this nonsense.
>
>
>
>
>>>
>>>Suppose you had no tricks, no extensions, no nothing. Just ab and a qsearch on
>>>top of it. You set an aspiration window at the root, say [200, 300].
>>>
>>>Now *if* the true ab value lies within this window, it should find it, right?
>>>
>>>WRONG!
>>>
>>>The fact that everyone has a
>>>
>>>      if(Eval >= Beta) return Beta;
>>>
>>>somewhere in the qsearch, makes that this no longer must be true. Reason:
>>>suppose you sacrifice lots of material, but can win more material back, due to
>>>severe mating threats, or whatever. With the window [240, 260] the qsearch
>>>concludes at some point to return Beta because of the material advantage (3
>>>pieces sacced), resulting in a fail-low on the [240, 260] window. However whith
>>>a wider window it can NOT do this, and finds the true value of 246. It now sees
>>>the material can be won back with rent.
>>>
>>>My conclusion is that a fail low on [240, 260] followed by a result of 246
>>>on [-inf, inf] is completely normal and unavoidable in many cases. It also
>>>explains this:
>>>
>>>  fail low on [240, 260]
>>>  fail high on [-inf, 241]
>>>  value = 246 on [-inf, inf]
>>>
>>>I don't like it. Suppose you start ab with [-inf, inf] and after a while
>>>alphabeta itsself has established a window of [x, y], halfway the search.
>>>Shouldn't the same phenomenon be possible?
>>>
>>>
>>>
>>>Regards,
>>>Bas Hamstra.



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.