Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Double Nullmove

Author: Dann Corbit

Date: 14:35:54 04/25/02

Go up one level in this thread


On April 25, 2002 at 17:12:12, Odd Gunnar Malin wrote:

>On April 25, 2002 at 15:27:26, Robert Hyatt wrote:
>
>>On April 25, 2002 at 13:49:42, Dann Corbit wrote:
>>
>>>On April 25, 2002 at 13:26:43, Robert Hyatt wrote:
>>>
>>>>On April 25, 2002 at 12:39:36, J. Wesley Cleveland wrote:
>>>>
>>>>>On April 25, 2002 at 02:54:03, Andreas Herrmann wrote:
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I want to implement double nullmove in my chess engine again. Now i'm searching
>>>>>>for Zugzwang postions, which should be solved by double nullmove instead of
>>>>>>normal nullmove.
>>>>>>Another question: How much time costs the double null move in the average.
>>>>>>I have tested it in some positions, and my engine needs about 30 to 40 percent
>>>>>>more time for the same search depth. Is that normal or is that to much.
>>>>>
>>>>>That seems like far too much. Are you reducing the search depth again for the
>>>>>second nullmove and only doing it when the first nullmove causes a cutoff? You
>>>>>might also not want to do it too near the leafs, i.e. if the first nullmove goes
>>>>>directly into your quiescence search.
>>>>
>>>>
>>>>One simple test... determine how often, in normal positions, the _second_ null-
>>>>move search fails high.  Whenever it does, the the first null-move search fails
>>>>low and is useless.  that is probably where the cost is being exposed...
>>>>
>>>>In zug positions, the second fail high will cause the first to fail low, which
>>>>prevents zug problems.  But if it also causes a large number of normal positions
>>>>to fail this test as well, then it is losing part of the advantage of null-move
>>>>in general...
>>>
>>>I had a notion about double null move --
>>>
>>>Implement double null move in the place where normally you will just turn null
>>>move off [except for check].  Use your regular null move algorithm as always,
>>>but when conditions indicate null move is not a good idea, switch to double null
>>>move.
>>
>>
>>If it was easy to identify positions where a null-move might cause problems,
>>the problem would already be solved.
>>
>>:)
>
>I think he thinking about:
>
>if (!incheck && !whatever)
>{
>  if (material > allow_nullmove)
>  {
>    ordinary nullmove
>  }else
>  {
>    double nullmove
>  }
>}
>
>I don't know if the better engines do it like, but I think many engines have a
>test on material.
>
>This was my first thought too when I saw the arguments.

That's the basic idea.  Everyone has some criteria where they turn off null
move.  You still have to bag it if in check, but otherwise, do a double null
move instead.  I had something like this in mind:

if (function_that_figures_out_if_null_move_is_safe())
   ordinary_null_move();
else
   if (!incheck)
      double_null_move();
   else
      full_search_not_performing_null_move();



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.