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.