Author: Uri Blass
Date: 23:52:11 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. My question was not about comparing using hash tables and not using hash tables but about comparing using hash tables in the normal way and using hash tables for all purposes except pruning. Uri
This page took 0.02 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.