Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Some questions about Verified Null-Move Pruning

Author: Uri Blass

Date: 09:01:54 11/22/02

Go up one level in this thread


On November 22, 2002 at 11:40:35, Tony Werten wrote:

>On November 22, 2002 at 10:59:33, Uri Blass wrote:
>
>>On November 22, 2002 at 10:52:03, Omid David Tabibi wrote:
>>
>>>On November 22, 2002 at 10:47:00, Uri Blass wrote:
>>>
>>>>On November 22, 2002 at 03:46:06, Tony Werten wrote:
>>>>
>>>>>On November 22, 2002 at 03:31:37, Uri Blass wrote:
>>>>>
>>>>>>On November 22, 2002 at 02:59:34, Tony Werten wrote:
>>>>>>
>>>>>>>On November 22, 2002 at 02:44:52, Tony Werten wrote:
>>>>>>>
>>>>>>>>On November 21, 2002 at 17:01:11, Omid David Tabibi wrote:
>>>>>>>>
>>>>>>>>>On November 21, 2002 at 16:55:04, Tony Werten wrote:
>>>>>>>>>
>>>>>>>>>>On November 21, 2002 at 16:19:17, Omid David Tabibi wrote:
>>>>>>>>>>
>>>>>>>>>>>On November 21, 2002 at 16:05:45, Tony Werten wrote:
>>>>>>>>>>>
>>>>>>>>>>>>On November 21, 2002 at 13:52:33, Omid David Tabibi wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>On November 21, 2002 at 13:05:28, Uri Blass wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>On November 21, 2002 at 09:16:09, Omid David Tabibi wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>On November 21, 2002 at 08:34:36, Uri Blass wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>1)I do not find in the pseudo code in figure 3 undo null move.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>I assume that it should be before if value>=beta and after value=-search(...)
>>>>>>>>>>>>>>>>Am I right?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>That is why it is called *pseudo*-code :-)
>>>>>>>>>>>>>>>You have to fill in the obvious parts by yourself...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>2)What is the value of the research for tactical strength?
>>>>>>>>>>>>>>>>Should it help significantly relative to searching to reduced depth when
>>>>>>>>>>>>>>>>value>=beta without research (even when we get value that is less than beta).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>I didn't understand the question. Dp you mean doing a shallow search even when
>>>>>>>>>>>>>>>we don't have a fail-high report?!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>I meant to ask what is the tactical value of the research(You suggested people
>>>>>>>>>>>>>>to start with doing it without the research first and only after it works to do
>>>>>>>>>>>>>>it with the research)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>The re-search is needed only in zugzwang positions. Such zugzwang positions
>>>>>>>>>>>>>occur very rarely in midgames; so you can forgo the zugzwang detection re-search
>>>>>>>>>>>>>and still benefit all the improved tactical performance.
>>>>>>>>>>>>
>>>>>>>>>>>>I was quite surprised to see them from the starting position at a rate of 5 per
>>>>>>>>>>>>second. Not impressive, XiniX searches 400 Kn/s there, but still surprising.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>The rate of what, was 5 per second?
>>>>>>>>>>
>>>>>>>>>>"Zugzwang positions" or rather, positions where nullmove would have given a
>>>>>>>>>>cutoff but that after reducing depth and searching gave a score < beta.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>You mean you got an average of 5 zugzwang indications per second in middle
>>>>>>>>>game?!!! Then your program has instabilities which cause a huge number of
>>>>>>>>>needless re-searches due to false zugzwang alarm. Turn off your zugzwang
>>>>>>>>>detection at once!
>>>>>>>>
>>>>>>>>I'm quite interested in finding out what is happening so I'll leave it in for a
>>>>>>>>while. I think it has something to do with tempo. XiniX doesn't use futility
>>>>>>>>pruning so I'm quite curious to know if programs that do, have a bigger false
>>>>>>>>zugzwang count.
>>>>>>>
>>>>>>>Think I found it. Your algoritm doesn't seem to work correctly with threat
>>>>>>>detection, causing instabilities. Maybe your testprogram didn't use it ?
>>>>>>
>>>>>>I do not understand
>>>>>>
>>>>>>Can you explain?
>>>>>>
>>>>>>I did not find something strange with the 5 "Zugzwang" per second in the opening
>>>>>>position because I assume that it is all about the horizon effect and not about
>>>>>>real zugzwang positions".
>>>>>
>>>>>Yes, and R=3 gets the horizon closer than R=2. Threats fe get found easier with
>>>>>R=2.
>>>>>
>>>>>Tony
>>>>
>>>>I now checked with movei and counted 63 horizon effects in the first 10,000,000
>>>>nodes.
>>>>
>>>
>>>By 63 horizon effects you mean zugzwang detection (they are two different
>>>things!)?
>>
>>The algorithm does not detect zugzwangs but cases when null move search return
>>beta and search to bigger depth returned a value that is smaller than beta.
>>
>>I do not believe in zugzwangs near the opening position so I guess that the
>>reason must be some horizon effect.
>
>I looked at some of the positions and they weren't zugzwang positions. So my
>best guess is also horizon. Probably combined with "tempo" wich is quite
>important in the beginning.
>
>Tony

It seems that I had a bug of initialized local varaible
First positions was no zugzwang

36 positions out of 10,000,000 if I have no bugs now.

Uri
>
>>
>>Uri



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.