Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Nullmove: when to avoid it?

Author: Robert Hyatt

Date: 10:19:45 02/28/01

Go up one level in this thread


On February 28, 2001 at 11:24:27, Leen Ammeraal wrote:

>On February 28, 2001 at 10:10:48, Robert Hyatt wrote:
>
>>On February 28, 2001 at 05:56:36, Leen Ammeraal wrote:
>>
>>>I am not sure about when to avoid nullmoves.
>>>I omit it:
>>>a. when in check
>>>b. when there are less than 5 pieces (including pawns) on the board
>>>c. when the last move was a nullmove
>>>d. at the root node
>>>Should I also omit it in some other cases,
>>>for example, when any hashmove (even with a low draft) was found,
>>>or when beta = alpha + 1?
>>>Thanks in advance for any help.
>>>Leen
>>
>>
>>B is dangerous.  You should probably begin to control / limit null-move if
>>there is a rook or less on the board + any number of pawns.  In such positions
>>zugzwang is likely and will cause null-move to fail improperly.
>>
>>your last question is easier.  Don't avoid null move just because a low-draft
>>position was found.  Look at the stored bound and the draft.  Compare the draft
>>to the draft you would be using if you played a null-move to see if this draft
>>is deep enough there (IE with R=2, you would be probing with depth-3 at the
>>next ply).  If you have enough draft for this test, then see if the score is
>>< beta.  If so, this is probably the same score that null-move search would
>>return since this is the score _before_ you make a move at this ply, and if
>>you make a null-move the position won't change.  If the hash score is < beta,
>>then a null-search won't fail high, and you can avoid doing it and save the
>>nodes.
>>
>>Look at crafty source, hash.c file, "HashProbe()" procedure in that file to
>>see exactly how I do this...
>
>Thank you for your explanation about when
>to avoid nullmoves. I found it
>easier to read than you code in the hash.c file -:)
>If I understand what you mean, I could use
>something like the following code, right?
>
>   bool avoidBecauseOfHash =
>     hashDraft >= reducedRecDepth &&
>     hashFlag != LOWER && hashScore < beta;
>
>I inserted the hashFlag condition because I thought
>that this should be EXACT or UPPER here: if
>hashScore is a lower bound, the true score
>may very well be above beta.

That is correct.  I simplify the test a bit as I use the following:

type=3 (EXACT), type=2 (UPPER) and type=1 (LOWER).  If I take
type & upper, that will be true if type = UPPER or type = EXACT.

LOWER is no good here as you mention...



>
>There is another point, unrelated to hashing,
>which I forgot to mention in my original question.
>Since we are hoping for fail high, it seems to
>me obvious that nullmoves are also useless if
>beta = inf, where inf is the maximum value,
>used in the largest possible window. Perhaps this
>is so obvious that nobody mentions it?
>Leen

True.  But with PVS hardly any nodes are searched with such a large upper
bound so it really doesn't matter much anyway...





This page took 0.03 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.