Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: NULL MOVE

Author: Peter McKenzie

Date: 01:40:59 02/25/99

Go up one level in this thread


On February 25, 1999 at 01:44:25, Will Singleton wrote:

>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
>>>>this.
>>>>
>>>>- 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?
>>>
>>>Will
>>
>>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.

There was a *huge* debate about this a few years back on r.g.c.c.
Bob Hyatt was involved, can't remember who else.  I personally don't allow two
nulls in a row, mainly because I don't want to hurt my brain thinking about it
:-)

Peter

>
>Will



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.