Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Null-Move: Difference between R = 2 and R = 3 in action

Author: Robert Hyatt

Date: 18:43:40 07/19/02

Go up one level in this thread


On July 19, 2002 at 15:50:44, Uri Blass wrote:

>On July 19, 2002 at 15:25:48, Christophe Theron wrote:
>
>>On July 18, 2002 at 12:14:10, Robert Hyatt wrote:
>>
>>>On July 18, 2002 at 05:58:56, Vincent Diepeveen wrote:
>>>
>>>>On July 17, 2002 at 13:18:40, Christophe Theron wrote:
>>>>
>>>>>On July 16, 2002 at 11:01:23, Vincent Diepeveen wrote:
>>>>>
>>>>>>On July 15, 2002 at 13:11:09, Christophe Theron wrote:
>>>>>>
>>>>>>>On July 15, 2002 at 08:37:34, Omid David wrote:
>>>>>>>
>>>>>>>>I don't think using double null-move is a good idea in practice, since in
>>>>>>>>midgame the chance of zugzwang is negligible and thus it's superfluous (I doubt
>>>>>>>>if even DIEP uses it). However the contribution of double null-move is that it
>>>>>>>>gives legitimacy to the null-move pruning idea, proving that it _is_ a correct
>>>>>>>>search method (anyway, no one doubts null-move nowadays).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Why does double null move prove that null move is a correct search method????
>>>>>>>
>>>>>>>Doing two null moves in a row means going back to standard search (a search not
>>>>>>>involving an illegal move like null move is).
>>>>>>>
>>>>>>>I fail to see how it legitimates null move.
>>>>>>
>>>>>>Double nullmove legitimates (duh can't you use easier to spell words)
>>>>>>itself, for the obvious reason that it is provable now that a search
>>>>>>depth of n ply, where i may pick n, is going to solve any problem you
>>>>>>give it.
>>>>>
>>>>>
>>>>>
>>>>>OK, I see now.
>>>>>
>>>>>However, it is not true.
>>>>>
>>>>>Due to a nasty interaction with the hash table algorithms, just allowing 2 null
>>>>>moves in a row will NOT solve any problem.
>>>>
>>>>What you refer to is a practical impossibility (assuming you have
>>>>a efficient search) :
>>>>
>>>>  your assumption is that from a root position r
>>>>  with transition of some moves to position p, side stm to move and
>>>>  depthleft=d:
>>>>
>>>>  r ==> p(stm,d)
>>>>
>>>>  that you visit this position with properties that
>>>>  before this move you have made 1 nullmove or less.
>>>>
>>>>  so ==> r , nullmove , p
>>>>
>>>>  Now a major problem for such an event to occur is that
>>>>  after 1 nullmove, sides change the side to move.
>>>
>>>Why is this a problem?  IE in my case, position P reached thru a path
>>>with a null-move and position P reached thru a path without null-move
>>>are _unique_ positions...
>>
>>
>>
>>If so, your programs loses a lot of opportunities to prune because it detects
>>less transpositions. But maybe it avoids some problems and is benefical in the
>>end, I do not know.
>
>How much do programs earn by pruning based on hash tables?
>
>Today I do not use hash tables to prune the tree.
>I am interested to know how much rating programs earn from
>using hash tables to prune the tree.
>
>1)Did someone do the experiment of comparing the rating of
>a chess program when hash tables are used only for things like order
>of moves and the rating of the same program when hash tables are used also for
>also to prune the tree.
>
>2)How much speed improvement do programs get in middle game
>from pruning based on hash tables?
>
>Uri


Try position fine 70 with and without.  Without you might get to depth 15
or so.  With it you can reach depth 40.  A _significant_ gain...



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