Author: Vincent Diepeveen
Date: 13:17:37 07/13/01
Go up one level in this thread
On July 13, 2001 at 14:25:23, Robert Hyatt wrote: >On July 13, 2001 at 12:28:01, Steve Maughan wrote: > >>I'm thinking of implementing double null move in my program. Now as far as I >>know the most conventional way is to do the normal null move search and if there >>is a cutoff follow it with a normal search at reduced depth to confirm no >>zugwag. However I do remember that someone here (Vincent?) outlined a different >>way of doing double null move. Is there another way? If there is, what are the >>pros and cons of each? >> >>Thanks, >> >>Steve > > >That's the gist of it. If the position is a zugzwang position, the second >null-move search will fail high, which will cause the first to fail low and >you don't run into the zug problem. > >The downside is the cost. The second null will fail low most of the time and >just generate wasted nodes. The downside is not the cost of the second nullmove, but preventing a third nullmove in a row. The best nullmove implementation is of course always nullmoving whatever happens. Even if a static evaluation is < beta then still nullmoving works way better: a) nullmove is nearly free of cost as it's like 1/bf^4 nodes of the current subtree, where bf is the branching factor b) perhaps there is a major threat which my opponent can't prevent, then i still fail high. >The other downside is that not all null-positions are zugzwang problems. In >fact, most null-move problems are caused by the R-value which bring the horizon >too close to spot a tactical threat. Double null won't find any of those... Double nullmove is a cheap way to use nullmove in the far endgame also without losing a huge number of plies. The big reduction (R=3 instead of R=2) factor which we nowadays all use already shows how little of loss a few ply of search depth is, as long as we replace the search by the best thing we have: another search. >So you expend quite a bit of effort, to eliminate one small part of the total >problem... > >That's why I don't do it myself.... The only faster thing as double nullmove is always nullmoving, this is a small subtree and we talk about a few nodes only. For that price you search in a correct way (so at a depth n you always find the solution of a problem). The only stage of the game where i turn nullmove off is if either side is in a pawn endgame. I do this dynamically in the search.
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.