# Computer Chess Club Archives

## Messages

### Subject: Re: Of course using search times it doesn't work

Author: Vincent Diepeveen

Date: 19:42:50 11/21/02

Go up one level in this thread

```On November 21, 2002 at 22:08:22, Uri Blass wrote:

>On November 21, 2002 at 22:00:21, Vincent Diepeveen wrote:
>
>>On November 21, 2002 at 21:43:46, Uri Blass wrote:
>>
>>>On November 21, 2002 at 21:38:43, Vincent Diepeveen wrote:
>>>
>>>>On November 20, 2002 at 16:55:41, Gian-Carlo Pascutto wrote:
>>>>
>>>>Of course it doesn't work for you. you compare searchtimes
>>>>with each other. In his article he compares search depths with
>>>>each other. He claims 10 ply fullwidth is better finding
>>>>a bit more at testsets than 10 ply
>>>>with nullmove for tactical reasons,
>>>>forgetting to tell of course what time it takes to get it.
>>>>
>>>>You are comparing search depths which is correct. He isn't.
>>>>See his article.
>>>
>>>He also did games and at least it was clearly superior in games relative to R=2.
>>>It may be interesting to find out if it is also superior in games relative to
>>>R=3 or relative to other algorithms.
>>>
>>>Uri
>>
>>It means his implementation of nullmove has a bug obviously.
>>
>>Also his 50% figure is wrong. He claims that R=3 always is
>>outperforming his algorithm only by factor 2.
>>
>>That is wrong. It should not be factor 2. It should be several
>>plies of course. And default R=2 also should outperform (timewise)
>>his algorithm bigtime. His tests don't show it.
>>
>>It is trivial that a reduction of 1 ply is going to be more expensive
>>than a nullmove reduction of R=2 + 1 = 3 ply.
>>
>>Do you see that too?
>
>No
>
>I see that after the first reduction of 1 ply you have a recursive null move
>pruning with no 1 ply reductions.
>
>I do not see a recursive null move pruning with no 1 ply reduction in part of
>the tree with R=2.
>
>I think that you should apologize for always assuming that other people have
>bugs.

No he has *major* bugs in his program.

Normal nullmove r=2
==> with a tree of R=2+1=3 ply reduction you give a cutoff.

He's doing also a nullmove after that a search of 1 ply reduction.

So if we assume a depth of 10 ply left, then the R=2 nullmove
search reduces to 7 ply. That 7 ply search cutoffs. That's it.

Omid is doing a nullmove also but after that he reduces 1 ply.
10 ply minus 1 = 9 ply. So he is claiming in his article that
a 9 ply search is more efficient than a 7 ply search.

That's not true of course.

It can only be explained by bugs in his program. For example
that he doesn't catch a hashtable probe or something which was
already based upon a reduced depth and now again gets
reduced ==> FHR bug problem.

Or some bug in nullmove.

>Uri

```