Computer Chess Club Archives


Search

Terms

Messages

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

Author: Uri Blass

Date: 07:41:04 04/28/04

Go up one level in this thread


On April 28, 2004 at 09:41:11, Vincent Diepeveen 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.
>
>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.

If a search full of bugs work for Omid then maybe they are not bugs but a good
decision.

>
>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
>P3-733Mhz.

As far as I know Falcon also has checks in the qsearch.
I hope you will see in the next WCCC that it is not weaker than the top
programs.

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

No

I do today verified null move pruning only in endgame.
I found that there are clearly cases when I find things 1 or 2 plies earlier
but it happens more in the endgame relative to the middle game.


 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.

I think that it is dependent on the program and if I remember correctly based on
my experience the loss is less than 1 ply.

Of course my program is different and I do not use hash for pruning but
I see advantage of not using hash for pruning and the main advantage is that you
have more freedom in the evaluation function and I can let myself to have
evaluation that is dependent not only on the leaf position.

Uri



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