Author: Vincent Diepeveen
Date: 13:44:56 03/30/01
Go up one level in this thread
On March 30, 2001 at 12:54:48, Robert Hyatt wrote: >On March 30, 2001 at 12:04:36, Andrew Dados wrote: > >>On March 30, 2001 at 11:17:22, Robert Hyatt wrote: >> >>>On March 30, 2001 at 09:04:25, David Rasmussen wrote: >>> >>>>Anyone who have tried double nullmove (I know you have, Vincent :), what are the >>>>_drawbacks_ of double nullmove? >>> >>> >>>There are two sides to this: >>> >>>1. you use the double null-move to detect zugzwang positions. Because if >>>a position fails high after the second null-move, it would have failed high >>>after the first as well and that is a strong indication of a zugzwang position. >>>And since the second null search fails high and returns beta, the first null >>>search will fail low and it won't be used. >>> >>>So you get zug detection and you can be more relaxed in where you try >>>null moves. Note that many null-move failures are _not_ zugzwang positions. >>>They are simply positions that look won to a less-than-normal search depth. >>>But in reality, a normal search would reveal they are dead lost. Double nulls >>>don't handle this at all, so you need some other protection. A classic is to >>>let your opponent get a pawn stuck at f6. If he gets a queen to h6, the mate >>>threat might be unstoppable on g7. But after playing Qh6, <null> you might >>>hit your q-search and never notice that Qg7 is mate. >>> >>>2. The double null move search is not free. It is a tree search that will >>>be used to signal (on a few occasions) that a previous ply null-search should >>>not be trusted due to zugzwang. The downside is this is pretty expensive. >> >>How expensive can double nullmove be? >> >>For bf of 3 you get about 1/3^3=1/27 more nodes. >>For endgames and bf of 2 you'll see estimated 1/8 more nodes. >> >>Actually my program uses double null in endgames and it seems 10% more nodes is >>maximal overhead I saw (compared to 'normal nullmove'). >> > > >that is the number I saw, roughly. Although on occasion it is much higher. >IE the second null-move search can explode with extensions in the right >cases. > > > > >>However in those low material situations when other programs disable nullmove >>totally (except for pawn endings) double nullmove is an obvious winner. >> >>-Andrew- > >yes it can be. Or you can be more selective and not disable null-move when >you have a single piece left, just be more careful about where you try them... if you have 2 pieces left on the board then the majority of nodes you see will be 1 piece. If you use double nullmove then, then you can happily nullmove in all those nonsense positions meanwhile you catch easily a single zugzwang. obviously the huge reduction factors nowadays used by programs (R=3) means that you need a big number of extra plies to see that zugzwang, which usually is no problem for the safety it returns. However most important feature of double nullmove is completely overlooked here. I didn't design double nullmove to improve my chessprogram. I designed it basically to show that using nullmove is a correct way of searching. Sometimes you need a bunch of plies more to reveal the truth about a position, especially if you don't do checks in qsearch after a queen lands on h6, though the reduction of 3 ply is obviously a big blow to see things if the evaluation doesn't see the problems. In short it seems everyone has accepted that nullmove works very well. With better evaluation, a few checks in qsearch, and some extensions you can even find so called 'anti-nullmove' problems reasonable quick, whereas in normal game play the problems are simply non-existing! Yet the hammering uncertainty that existed some years ago which seemed to let nullmove more look like a form of dubious pruning, this is completely removed. It seems however to me that the 'uncertainty' left about nullmove in publications is basically only caused by dubious other forward pruning, as the combination of a big reduction factor and forward pruning is of course deadly to find unforced tricks, but great to increase the search depth variable! To my big surprise double nullmove appeared to work very well in far endgame. Of course seeing more than 2 non-PV zugzwangs is pretty hard. Yet the PV gets checked to huge depths which is very important, whereas otherwise you just search a few ply, but usually like 4 to 10 ply less as with double nullmove. Exceptions where nullmove isn't giving more depth as normal search are usually evaluation dependant. I have actually 1 such a position and it appears the problem is that every good move in the position is about last to get found in my move ordering and evaluation is only corrected by search. Yet the important positions before that where you need to see the exchanges to the far endgame, that's the point where double nullmove works brilliant. Of course it is simple truth that *always* nullmoving is needing a bit of nodes less. In DIEP i never measured too accurately whether that's 1% nodes on average or whether it's less as that, but i tested it to be that little that i didn't want to lose my double nullmove for that! Note that most of those nodes are cheap anyway, you get them from transpositiontable and evaluation table already! Best regards, Vincent >>>On one hand, you catch zugzwang positions. On the other hand, you make the >>>tree larger. Which is better? It is just another compromise decision where >>>you win some and lose some because of it.
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.