Computer Chess Club Archives




Subject: Re: new thoughts on verified null move

Author: Uri Blass

Date: 11:06:05 11/23/02

Go up one level in this thread

On November 23, 2002 at 13:00:34, Martin Giepmans wrote:

>On November 23, 2002 at 12:10:02, Uri Blass wrote:
>>On November 23, 2002 at 11:37:25, Martin Giepmans wrote:
>>>On November 23, 2002 at 08:48:36, Omid David Tabibi wrote:
>>>>On November 23, 2002 at 08:45:00, Uri Blass wrote:
>>>>>On November 23, 2002 at 08:11:37, scott farrell wrote:
>>>>>>Just after other people's thoughts.
>>>>>>I think Omid's work overlooked the adapative null move searching many of us do,
>>>>>>ie. transitioning from r=3 to r=2.
>>>>>>I think adaptive null move tries to GUESS where to use r=2 to reduce the errors
>>>>>>that R=3 makes. I guess it depends on how often this GUESS is correct, the cost
>>>>>>of the verification search, and how long it takes the adaptive searching to
>>>>>>catch the error at the next ply.
>>>>>>Has anyone looked at setting the verification search to reduced depth of 2
>>>>>>(rather than 1)? obviously to reduce the cost of the verification search.
>>>>>Omid checked it but you also reduce the gain.
>>>>>I think that I will look for good rules when to do the verification search so
>>>>>the cost will be significantly smaller but the gain is going to be the same in
>>>>>at least 99% of the cases.
>>>>I'm currently working on other variations. The initial results are promising.
>>>I have done some tests with your method at greater depths.
>>>At depth 12 vrfd R=3 still had an overhead (in terms of treesize) of about
>>>25% compared to pure R=3.
>>>(my engine uses a simple Q-search that shouldn't give problems here)
>>>So the question is if your expectation that the treesize of R=3 and vrfd R=3
>>>converge at greater depths (> 11) really holds.
>>>Needs more testing, I think.
>>>Another point:
>>>I would expect that vrfd R=3 becomes less safe at greater depths.
>>>The subtrees in which you don't verify nullmove (after the verification) become
>>>deeper and I see no reason - on logical grounds - why this shouldn't give safety
>>>Even if R=3 and vrfd R=3 converge in terms of treesize, the safety (or rather
>>>the lack of it) might also converge ...
>>>In any case, thanks for sharing.
>>I see reasons why the safety does not converge.
>>A common problem with null move is cases when the first move has a threat but
>>the threat can only be seen at big depth.
>>With verified null move pruning you are going to see the threat clearly earlier.
>>When the threat is in a move that is not close to the root then the danger of
>>being wrong in detecting the threat is smaller because you can miss one threat
>>but another threat may give the same result.
>I think it will be clear if you replace the somewhat confusing expression "close
>to the root" by "distance to the leaves".

I do not see the confusion because distance to the leaves has opposite meaning
to distance to the root.

In terms of distance to the leaves(remaining depth) I say the following:

It is more important to detect threats when the distance to the leaves is big.

The point is that when the distance to the leaves is small even if you are wrong
in detecting threats there is a good chance that it is going to change nothing
in the final score.

I also have examples when the algorithm save me 2 plies when the depth is big.

Here is one of them.

Latest movei need 11 plies when previous movei needs 13 plies and a long time to
solve the fail high

[D]r1bq1rk1/3pbppp/p1n1p3/4P3/2B1NP2/PP5Q/1B4PP/3R1R1K w - - 0 1

depth=11 +1.20 f4f5 e6f5 e4d6 e7d6 e5d6 d8g5 f1f5 g5g6 h3h5 g6h5 f5h5 c8b7
Nodes: 15025408 NPS: 158378
Time: 00:01:34.87

depth=11 +1.21 e4f6
Nodes: 18075970 NPS: 158979
Time: 00:01:53.70

depth=11 +3.72 e4f6 e7f6 e5f6 d7d5 c4d3 h7h6 f6g7 f8e8 h3h6 f7f5 d3f5 e6f5 h6c6
Nodes: 69601416 NPS: 156492
Time: 00:07:24.76

I did not analyze the reason for the difference but it is possible that movei
saw no threat after Nf6+ gxf6 exf6 and verification search helped it to see the


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