Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: When to do a null move search - an experiment

Author: Ed Schr÷der

Date: 10:45:05 04/28/04

Go up one level in this thread


On April 28, 2004 at 01:29:30, Gerd Isenberg wrote:

>On April 28, 2004 at 01:11:23, Gerd Isenberg wrote:
>
>>On April 27, 2004 at 21:54:49, Uri Blass wrote:
>>
>>>On April 27, 2004 at 21:00:22, Vincent Diepeveen wrote:
>>>
>>>>On April 27, 2004 at 11:43:36, JosÚ Carlos wrote:
>>>>
>>>>>On April 27, 2004 at 08:37:34, Tony Werten wrote:
>>>>>
>>>>>>On April 27, 2004 at 03:33:26, Bas Hamstra wrote:
>>>>>>
>>>>>>>About double nullmove: I tested this in some pawnendgames to see if it could
>>>>>>>handle zuzwang problems, but I don't see it perform any better than normal
>>>>>>>nullmove. Can Vincent or you post a position where double null outperforms
>>>>>>>normal null? I agree the idea is elegant, but I just don't see it work.
>>>>>>
>>>>>>I switch it off in pawns only endgames. Couldn't figure out why it wasn't doing
>>>>>>as well as it sounded.
>>>>>
>>>>>  I can't think about it now, but I recall this thread where an interesting
>>>>>discussion about double null move came up:
>>>>>
>>>>>http://chessprogramming.org/cccsearch/ccc.php?art_id=241476
>>>>>
>>>>>  JosÚ C.
>>>>
>>>>Christophe wrote that down just to let you guys believe you should search
>>>>fullwidth.
>>>>
>>>>Practical chances of it happening is small, not zero but very close to it.
>>>>Additionally you can add a single 'if then else' condition in transposition
>>>>table cutoff to avoid the theoretical scenario that christophe describes.
>>>>
>>>>Look the alternative to double nullmove is doing something dead slow like what
>>>>Gerd is doing, or what i used to do in my draughtsprogram; a verification
>>>>search, which is just a fullwidth search of n-R ply. So not the later posted in
>>>>ICGA verification search. Verification search already was excisting in other
>>>>publications than in the ICGA. So Omid just stole the name kind of for something
>>>>working crappy :)
>>>
>>>No
>>>
>>>Omid did not steal the idea.
>>>
>>>You simply did not understand Omid's ideas.
>>>Omid's idea is not mainly to detect zugzwangs but to detect tactics earlier.
>>>
>>>Null move pruning means that there are tactics that you need more plies to see
>>>because of the horizon effect when you cannot detect the threat.
>>>
>>>With verified null move pruning you can see it 1 or 2 plies earlier.
>>>
>>>Doing checks in the qsearch cannot solve the problem because there is tactics
>>>that is not based on checks.
>>>
>>>>
>>>>Basically all those approaches eat shitload of nodes to say it *very* polite.
>>>
>>>Basically I see no reason that verification search to detect zugzwangs needs to
>>>eat many nodes(Omid's idea is not verification search) and common sense tells me
>>>that if the depth is reduced enough it does not eat many nodes.
>>>
>>>Uri
>
>oups, sorry for the empty reply...
>
>I tried double nullmove suggested by Vincent too, without any precondition like
>eval - margin >= beta. Vincent is probably right - it seems to work great, and
>solves a lot of test positions a few percent faster. But with some positions,
>specially with fail-high or -low behaviour the solution needs more than the
>double time than single nullmove in a row with verification search in my
>program. Two examples from BT-test:

What is double nullmove? I only know recursive nullmove allowing multiple
nullmoves. I also read about "allowing 2 nullmoves in a row". What are the
differences?

I use recursive nullmove, not allowing the next ply after the nullmove to
nullmove. So:

  e2-e4
  e7-e5
  **-**     // nullmove
  d7-d5     // do no allow nullmove

When I remove that check I get a few percent speedup, results look okay.

Ed



This page took 0.02 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.