Author: Sune Fischer
Date: 04:01:12 02/21/02
Go up one level in this thread
On February 21, 2002 at 06:19:47, Uri Blass wrote: >On February 21, 2002 at 04:59:12, Sune Fischer wrote: > >>On February 21, 2002 at 00:18:09, Uri Blass wrote: >> >>>On February 20, 2002 at 19:18:51, Vincent Diepeveen wrote: >>>>>no no i do not mean hashtable. i mean ARRAY with hashcodes >>>> >>>>all you have to do is: >>>> >>>> for f=current move to 1 f = f -2; >>>> if( hashcode[f] == currenthash ) >>>> return(drawscore); >>> >>>The question is if there is no small risk of wrong repetition detection. >>>In my program wrong repetition detection can happen only because of bugs and in >>>this case I guess that hashcode[f] is some compression of the position to 32 >>>or 64 bit number and it may be the same for different positions. >>> >>>I guess that in the case of 64 bit number the risk is practically 0. >>> >>>Uri >> >>There is no risk to the above method, it works perfectly if you use 64 bit. >> >>I talked to Bruce Moreland about this, it seems *safer* and easier than what he >>proposes at http://www.seanet.com/~brucemo/topics/repetition.htm >> >>He replyed, that he was worried that it would be too slow to do a O(N) search at >>every node. The hashing method requires only a few lookups. >>However, rep. detec. is not needed in qsearch and most of the time the search >>will break quickly because last or previous move was not a "reversible" move >>(you should add a break statement to that code Vincent:). >> >>Bruce did suggest there could be a problem in the endgame if you get close to >>the 50 move rule, then you will be doing a O(50) linear search at every node!! >> >>-S. > >O(50) is not so big and it is not going to happen in every node in the >search(even in that case I believe that the difference in speed is not more than >10%). Your 10% seems like a wild guess, why not 50%? Do you have 500 conditionals in your eval or something? Imagine a complicated Q vs R endgame, there won't be many captures and you will in the search get close to the O(50) per node, of cause how often does a position like that occur, especially with EGTB. My fear is, that one day a position like that will be played, naturally it will be in a very large and important tournament, and you search will grind to a halt. >A lot of these positions are dead draw and you do not need to worry about >them. Hmm, but you won't know that until O(50) checks later... I think the hash method is faster, generally, because it can do the same in only 1 lookup (and because so many are using it:). One thing that worries me more is how to use the hash scores, the score saved in the hash was from a different search where there might not have been a repetition. Searching the position now may yield a different result because of repetions. I wonder if this is fixable? >Uri -S.
This page took 0 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.