Computer Chess Club Archives




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

Author: Vincent Diepeveen

Date: 06:41:11 04/28/04

Go up one level in this thread

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:
>>>  Josť C.
>>Christophe wrote that down just to let you guys believe you should search
>>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 :)
>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.

What i refer to is that the original 'verification search' was doing a kind of
fullwidth search as a replacement of nullmove. Omid then later made a
'verification search' which is sometimes doing a 1 ply search near the leafs
depending upon when you try it, full of hashtable bugs.

So there is 2 algorithms called verification search both doing a different thing
but having the same intention.

Further Omid never has proven his verification search is tactical stronger
because he compared search depths, not search times and he did it with a program
that is so crappy that any modification to the program would be good.

The stronger programs however have checks efficiently implemented in search and
do not do the dubious forward pruning that Omid is doing with Falcon at his

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

No you are not seeing things 1 or 2 plies earlier. Not at all. You just lose a
ply in search depth to it, that's all. And it's buggy implementation will cause
you to not profit from it at a crucial time.

>Doing checks in the qsearch cannot solve the problem because there is tactics
>that is not based on checks.

Not doing too dubious forward pruning the last so many plies and making an
efficient search with checks in qsearch of course plays even better *and* is
tactical stronger.

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

Common sense testing tells us that verification search loses a full ply of
search depth compared to R=3.

And any approach either taken by Heinz or me in order to vary R depths are not
compared against it objectively.

So todays methods completely outgun this dubious implemented thing which reused
an existing name for its algorithm.


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