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