Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: null move efficiency

Author: José Carlos

Date: 02:06:17 04/20/04

Go up one level in this thread


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?

  I had this condition in Averno for a long time. Once, I was thinking about
some search instability and I came to the conclusion that it was a mistake,
because I was doing threat extensions (when null move returns a mate score
against me I extend), so I failed high in a non PV variation, then I tried an
open window and failed low because I was missing that necessary extension to
justify the fail high.
  So definetely, yes: try null move in the PV.

>>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.

  Do you mean recursive null move (which is fine) or actually doing several null
moves in a row without a 'real' move in between. If the later, I don't
understand it, because you would be dropping to qsearch at any search depth. (?)


>>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.
>
>Tord

  I tried this and the tree went bigger. The reason is that, many times, you
have a threat against the opponet so that, even if you're below in material and
he moves twice, he fails low. I changed it to "if opponent king safety is ok,
and no opponent pieces are attacked by my pieces and my eval is clearly below
beta then don't try null move".

  José C.



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.