Computer Chess Club Archives




Subject: Re: Repeatability (questions for Omid)

Author: Uri Blass

Date: 06:49:00 12/19/02

Go up one level in this thread

On December 19, 2002 at 09:32:40, Martin Giepmans wrote:

>On December 19, 2002 at 08:57:50, Uri Blass wrote:
>>On December 19, 2002 at 08:47:02, Martin Giepmans wrote:
>>>On December 19, 2002 at 01:46:01, Uri Blass wrote:
>>>>On December 18, 2002 at 22:19:24, Martin Giepmans wrote:
>>>>>On December 18, 2002 at 21:51:20, Omid David Tabibi wrote:
>>>>>>On December 18, 2002 at 21:44:09, Martin Giepmans wrote:
>>>>>>>>>I don't understand what you are trying to say.
>>>>>>>>>Without a research (if the verification search with reduced depth doesn't
>>>>>>>>>give a cutoff) verification search would be pointless.
>>>>>>>>The verification search goes deeper than the null-move search, so it might find
>>>>>>>>tactical errors overlooked by the null-move search, and correct them (without
>>>>>>>>any need for a re-search).
>>>>>>>No need for a research ??????????
>>>>>>>It's late, I guess we are talking about two different things?
>>>>>>No we aren't :-)
>>>>>>When we have a fail-high report, we simply reduce the depth, and continue a
>>>>>>regular search, as if nothing has happened. Because this regular search (which
>>>>>>can be called verification search) goes deeper, it might find out threats beyond
>>>>>>null-move search's horizon. In that case, you would get the correct result even
>>>>>>if you don't do a re-search!
>>>>>Yes, we _were_ talking about 2 different things :)
>>>>>My thing is verification search, yours is what I would call "de-extension".
>>>>>One difference is that de-extensions are symmetrical (you reduce depth for
>>>>>both colors) while (standard) verification search is essentially asymmetrical.
>>>>>I think it's possible that at least some of the readers of your article
>>>>>got confused here and implemented something in their programs that you
>>>>>didn't intend. Perhaps that explains why in many cases your method didn't
>>>>>seem to work.
>>>>I do not understand
>>>>How can you reduce depth for only one color?
>>>>There is only one varaible with the name depth in my program.
>>>That's right, but the effect is asymmetrical.
>>>It's the same with nullmove.
>>>Suppose a program has white and only uses nullmove on ply 2.
>>>The effect is that it may overlook a good continuation for white, but
>>>_not_ for black. Nullmove pruning is (in effect) asymmetrical.
>>If it only use null move on ply 2, but programs do not do it.
>>>Standard verification search (always research) is also asymmetrical.
>>>If you leave out the research it becomes symmetrical: it may
>>>overlook good continuations for _both_ sides.
>>>I think there is a fundamental difference between vs with and without
>>I agree that there is difference but not because of not symmetric searching but
>>because it is possible that the research gives you better information at the
>>cost of time.
>It's not so easy to figure this out, but my hunch is that verification of
>nullmove without research is in fact incorrect.
>What is verified in this case? Nullmove pruning? Not exactly ...

without research it is simply a negative extension.
I do not see what is not correct with negative extension.

>Of course I know that many things that we use in our programs are not
>100% correct. "search instabilities", hmm, I don't like them, do you?

I have search instabilities but the question is if it is possible to avoid them
and do the program better.

I found a case that my program could find some tactic at depth x but not at
depth x+1 or x+2(only at depth x+3 it could find it again)

I found it simply by telling it to increase depth in a specific node.

I found that when I increase depth by one or two it suddenly cannot find the
tactics and only when I increase it by 3 it can find it.

I suspect that I cannopt avoid it if I want to do my program better.


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