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.13 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.