Author: Roberto Waldteufel
Date: 10:33:03 10/01/98
Go up one level in this thread
On October 01, 1998 at 12:59:20, Bruce Moreland wrote: > >On October 01, 1998 at 07:58:57, Roberto Waldteufel wrote: > >>The only problem I have encountered with method 2 is that draws correctly >>identified by the draw hash table will have an adverse affect on the scores of >>ancestor nodes in the tree when they are entered into the transposition table >>later on, and so a later hit on one of these ancestor nodes may give misleading >>information. I don't really see a way to avoid this - it seems at least to be a >>rare event. > >When you detect a repetition, just return instantly. I don't know how your >program is structured, but in mine, I can just return out of the search function >at that point, and conveniently forget to store the result. Yes, this is what I do now. >Of course, if the draw score is a fail low, you'll get a fail high when you >return, and you'll store that score. > >Which brings up a point I don't fully understand. People are concerned about >hashing draw scores because they don't want incorrect information in their hash >table. But you will always get incorrect information in your table, even if you >have a constant value for a draw, and your hash store function has a hook in it >that says never hash this score. > >When you detect a repetition, sometimes you'll have to select a different move >in order to avoid it, and the score of this gets hashed. Other times, when you >find this position, and you have a choice between the move that was a repetition >in the other position, and the move you chose instead, now you'll want to choose >the repetition move, because it's no longer a repetition. So what you get is an >erroneous score in the hash table, but it's not the draw score in the table, >it's the score of that second move. > >You get similar problems when you start doing extensions and pruning that are >based upon alpha. In one place you'll cut off and in another place you won't. >So you're always going to have the general problem, I think, of positions that >fail high when you search them, then fail low when you re-search them. These are exactly the sort of problems I am worried about, but...... > >I just ignore this problem and cross my fingers, and this seems to work fine. > Same here. I don't see any evidence of the search suffering, but it irks me to know it could....:-) Roberto >bruce
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.