Computer Chess Club Archives




Subject: Re: NULL MOVE

Author: Will Singleton

Date: 22:44:25 02/24/99

Go up one level in this thread

On February 25, 1999 at 01:17:35, Don Dailey wrote:

>On February 24, 1999 at 21:52:21, Will Singleton wrote:
>>On February 24, 1999 at 15:53:49, Don Dailey wrote:
>>>Your statement about not using two null moves in row shouldn't matter.
>>>I had this rule in my program and Don Beal asked me, "why?"  I took
>>>it out and the program worked fine.   I think a few years ago
>>>my implementation of null move needed this rule to prevent infinite
>>>recursion, but I cannot remember for the life of me why this was so.
>>>The worst that can happen is that you do more  depth reduced
>>>searches which is such a tiny fraction of the whole you will not be
>>>able to measure the difference in time.   But even this won't happen
>>>if you do not do a null move search when the "stand pat" score is
>>>already below beta.  Some programs do the null move selectivity anyway,
>>>or they do it if the score is CLOSE to beta.  However I decided to
>>>ignore any minor speedups this gave because it also introduces
>>>some risk.  I really doubt you can prove one is better than the
>>>other and my current program doesn't even register a speedup for
>>>- Don
>>Two nulls in a row??  I don't understand that.  How could either side move at
>>all if you have consecutive null moves?  Or maybe you mean multiple nulls along
>>the same branch?
>I mean consecutive null moves.  Player A makes a null move and the first
>thing Player B tries is also a null move.  If player A thinks he is winning,
>then player B's null move search will fail and he will be forced to resort
>to the full width search. This full width search is what will be returned
>to player A, NOT the result of a series of consecutive null moves.
>Remember, a null move result will only be returned for one side and
>only if that side is happy (happy means >=beta)  It is true that if you
>are doing a very deep search you will get some, even several consecutive
>null moves, but at least one side (and possibly both) will reject this.
>Perhaps another way to think about it is this:  Pretend that your
>move generator returns all the legal moves plus a NULL or PASS move.
>Your search may generate lots of lines where players make several
>consecutive null moves.  But unless these actually produce a beta
>cutoff (or zugzwang) they will get ignored.
>This clearly will not break the chess program and in fact you have
>just implemented a null move search, although a bad one since there
>is no depth reduction.   So just add depth reduction and you have
>a real null move implementation!
>- Don

What a wild idea.  Thanks for posting this.  I've never read about this in the
literature, but I probably just missed 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.