Author: Ricardo Gibert
Date: 20:12:28 07/19/02
Go up one level in this thread
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.
This page took 0.01 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.