Computer Chess Club Archives


Search

Terms

Messages

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

Author: Robert Hyatt

Date: 19:25:07 07/20/02

Go up one level in this thread


On July 19, 2002 at 23:12:28, Ricardo Gibert wrote:

>On July 19, 2002 at 23:08:16, Robert Hyatt wrote:
>
>>On July 19, 2002 at 22:15:31, Ricardo Gibert wrote:
>>
>>>On July 19, 2002 at 21:43:40, Robert Hyatt wrote:
>>>
>>>>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...
>>>
>>>You're trying to drive Uri crazy aren't you?
>>>
>>>Did you really think Uri could not think of an example of a position where
>>>having hash tables makes a significant difference?
>>>
>>>Do you really think being able to search a position like Fine 70 to a depth of
>>>40 instead of 15 will make a difference in a programs playing strength?
>>>
>>>Don't you realize people are liable to react to such a reply as yours above as a
>>>troll?
>>>
>>>Please try to be a bit more thoughtful.
>>
>>
>>There was _no_ troll involved.  Point by point.
>>
>>fine 70 _is_ an important hash test. It represents a near-best-case for
>>hashing.  Which is the best you can do.  It increases the search depth by
>>at least a factor of 3x in terms of plies searched.
>>
>>Will that help the program?  Clearly in king and pawn endings I see 20+ ply
>>searches _all_ the time.  And _that_ definitely helps for those positions where
>>K+P endings are reached.
>>
>>But if you want to take a middlegame position, hashing is worth at least a
>>factor of 2x based on tests I have run in the past.  I can always run them
>>again.
>>
>>So to summarize, fine 70 was and is legitimate.  It _clearly_ shows that
>>hashing makes a significant difference.  I hardly see why _your_ post wouldn't
>>be considered a "troll" in fact.  As it attacks a legitimate point in a
>>utterly simplistic and wrong context...
>>
>>Perhaps you should follow your own advice and try to be more thoughtful.
>>_prior_ to posting???
>
>I did. You didn't...again.

Excellent response.  Lots if informative and qualitative analysis.

Just like the previous post you wrote.



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