Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: null move efficiency

Author: Tord Romstad

Date: 03:47:34 04/20/04

Go up one level in this thread


On April 20, 2004 at 06:40:34, Tony Werten wrote:

>On April 20, 2004 at 06:36:35, Tony Werten wrote:
>
>>On April 20, 2004 at 04:50:19, Tord Romstad wrote:
>>
>>>On April 19, 2004 at 20:38:47, Mike Siler wrote:
>>>
>>>>My program tries a null move search if
>>>>
>>>>1. it's not the endgame
>>>
>>>This is far too restrictive.  Be careful about allowing null move pruning in
>>>pawn endgames and endgames where one side has only the king left, but in more
>>>complicated endgames the speed gain more than outweighs the risk of
>>>occasionally overlooking a zugzwang.
>>>
>>>>2. it's not a PV node
>>>
>>>Have you tried removing this condition?
>>>
>>>>3. it didn't just make a null move
>>>
>>>This just complicates the search for no good reason, I think.  Many people
>>>avoid more than one null move in a row, but I don't unerstand why.  I've
>>>never seen any bad effect of allowing successive null moves.
>>>
>>>>4. it's not in check and wasn't in check on the previous ply
>>>
>>>The "check on the previous ply" condition should almost certainly be
>>>dropped.
>>>
>>>>5. the remaining depth isn't so small that the reduced depth would take it into
>>>>the qsearch
>>>
>>>This is also a bad idea, I'm afraid.  It would render you null move search
>>>much less effective.  I know that some people (Bob, for instance) uses a
>>>lower null move reduction factor when the remaining depth is small, but
>>>I don't know any nullmovers who disable null moves entirely in this case.
>>>
>>>But you do not mention the most important condition of all:  Only do null
>>>move in nodes where you have a good reason to believe that you will fail
>>>high!  If the static eval is far below beta, doing a null move search is
>>>almost certainly a waste of time.
>>>
>>>As a start, I think the following two conditions should be sufficient:
>>>
>>>1. Don't make a null move if the side to move is in check (or is threatened
>>>   by a mate in 1, if you have an easy way to detect this).
>>>
>>>2. Don't make a null move if the static eval is far below beta.
>>
>>Actually, you can drop 2 as well :)
>>
>>Move ordering is much better if you just nullmove everywhere. That way, you can
>>also throw out IID.

That's not my experience.  Nullmoving everywhere doesn't noticably improve
my move ordering, and it increases the size of the game tree (by around
15-20%, if I recall correctly).  Throwing out IID doesn't help.

Perhaps this depends on how your move ordering works.

>In addition, throw out the 2nd half of 1 as well. If my opponent is going to
>checkmate me, I want to know so I can extend.

I don't understand what you say here.  In the 2nd half of 1, I suggested to
avoid null move search if you already know (without search) that mate in
1 is threatened.  What extra information do you expect to get from a null
move search?

Tord



This page took 0.01 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.