Computer Chess Club Archives


Search

Terms

Messages

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

Author: Robert Hyatt

Date: 08:20:59 11/29/02

Go up one level in this thread


On November 29, 2002 at 08:46:06, Omid David Tabibi wrote:

>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.
>

Not yet, no.  It is on my list of things to try however...



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



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