Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Verified Null-Move Pruning, ICGA 25(3)

Author: Omid David Tabibi

Date: 05:46:06 11/29/02

Go up one level in this thread


On November 28, 2002 at 20:08:42, Robert Hyatt wrote:

>On November 27, 2002 at 16:53:29, Tony Werten wrote:
>
>>On November 27, 2002 at 15:15:50, Robert Hyatt wrote:
>>
>>>On November 27, 2002 at 13:48:50, Frank Phillips wrote:
>>>
>>>>On November 26, 2002 at 20:02:06, Robert Hyatt wrote:
>>>>
>>>>>On November 26, 2002 at 16:21:00, Omid David Tabibi wrote:
>>>>>
>>>>>>On November 26, 2002 at 15:58:06, Gian-Carlo Pascutto wrote:
>>>>>>
>>>>>>>On November 26, 2002 at 15:55:56, Omid David Tabibi wrote:
>>>>>>>
>>>>>>>>So it is reasonable that on every program starting from a certain depth >adaptive null-move pruning will always construct a smaller search tree.
>>>>>>>
>>>>>>>Don't you mean the other way around?
>>>>>>>
>>>>>>
>>>>>>Yes :-)
>>>>>>
>>>>>>Starting from a certain depth, verified null-move pruning will always construct
>>>>>>a smaller search tree than the adaptive one.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>--
>>>>>>>GCP
>>>>>
>>>>>
>>>>> I am doing some testing now.  First thing I noticed is that for WAC, the
>>>>>time-squared
>>>>>measurement went down very significantly for your algorithm.  And I have not
>>>>>modified
>>>>>anything such as turning null-move off when low material happens, since your
>>>>>idea will
>>>>>catch the zug problems.
>>>>
>>>>Have you tried Fine70?
>>>>
>>>>Frank
>>>
>>>Yes...  and I told Omid that this is a strange case as if I allow null-move in
>>>pawn-only
>>>endings, which turns it on for fine 70 of course, things get wrecked inside the
>>>search
>>>somehow.  A 45 ply search fails to see that Kb1 wins where normally an 18-19 ply
>>>search is enough...
>>
>>Instead of one verification flag ( I implemented it as a global variable, was
>>easiest ) you need 2. One for black, one for white.
>>It only costs a few extra nodes, but you solve the problems of both sides being
>>in zugzwang somewhere in the search.
>>
>>Tony
>
>That is easy enough to do but I don't think it will solve the problem,
>since there are _many_ null-move searches that don't get verified, and those
>are all subject to zugzwang...
>

Did you try using a reduction of 2 after fail-high report, and doing verified
search also in the subtree (i.e., never cutting off based on the null-move
search alone)? This will definitely solve any zugzwang correctly.


>
>>
>>>
>>>
>>>>>
>>>>>



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.