Computer Chess Club Archives


Search

Terms

Messages

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

Author: Vincent Diepeveen

Date: 14:50:43 04/28/04

Go up one level in this thread


On April 28, 2004 at 17:36:26, Vincent Diepeveen wrote:

>On April 28, 2004 at 17:04:27, Gerd Isenberg wrote:
>
>>On April 28, 2004 at 16:50:56, Vincent Diepeveen wrote:
>>
>>>On April 28, 2004 at 15:03:41, Gerd Isenberg wrote:
>>
>><snip>
>>
>>>>I thought BT-test positions are from some gm matches?
>>>
>>>They just have tried to locate anti-positional near to random positions where
>>>computers had problems with AFAIK and nullmove especially.
>>>
>>>So positions where bruteforce is not doing bad.
>>
>>aha, interesting.
>>
>>>
>>>So if you do less selective search somehow in such positions, especially near
>>>the leafs knowing the poor qsearch from isichess, i am sure that will be
>>>helpful.
>>>
>>
>>I'm always impressed how you appraise other programs.
>>Thought my qsearch and huge eval too is one of the most sophisticated ;-)
>>
>>>As long as you do not realize that, then we will continue misunderstanding each
>>>other here.
>>>
>>
>>Sorry i don't get that.
>>Anyway thanks for your stimulations and lessons.
>>
>>Gerd
>
>It's not meant as a lesson. And i definitely do not want to get down your work.
>But i hope you realize the only thing Omid's verification search implementation
>is doing is at the first few nodes, especially those crucial nodes around PV to
>add another ply of search at the last ply.
>
>Just write down for the first 100 inner nodes you visit (not counting qsearch)
>what *exactly* it is doing.
>
>It just adds a ply of search there.
>
>So trivially you are missing something either in eval or qsearch then.
>
>The difference with adaptive nullmove is just that it always adds that ply, so
>adaptive nullmove will protect the PV just as good as find other shots.
>
>I never knew what to do the last 4 ply of my search. We all struggle with the
>same problems there. I do know however that verification search is not the way
>to go as it has hashtable bugs.

by the way the emergency solution i do now in diep which works bad is:

I try R=3 always.

If depthleft == 4 && eval(position) < beta+450 then try R=2

It sucks.

I'm going to do something else there. Johan had to tell to me again the truth
there in ict4 on how bad diep sucks there :)

That's what people do not realize here at CCC. In those tournaments i learn more
than at internet *ever*, simply because no commercial is objectively posting
here but just seeing it here as a chatbox.

Yet the above code is already working a lot better than verification.
Verification will always add a last ply which doesn't ever happen here.

So the overhead of verification search is *huge*, especially if you consider how
big my qsearch is.

80%+ of all diep's node in openings search are already qsearch nodes.




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.