Author: Tom Kerrigan
Date: 14:47:15 04/13/00
Go up one level in this thread
On April 13, 2000 at 15:10:25, KarinsDad wrote: >On April 13, 2000 at 12:19:45, Tom Kerrigan wrote: > >[snip] >> >>Now I'm confused. :) Are you talking about doing a search A and during that >>search, it overwrites a hash entry made by the same search (A)? >> >>-Tom > > >This is how I'm looking at it. We do search A with counter 23. We find a node in >the current search in the tree. It has counter 22 (it was entered last search) >and is the same position. Fine. We move on in the search. Later on, we find a >node that has counter 23, but is not the same position. We are fairly confident >that we placed it here in search A. We have to decide whether to keep it or >overwrite it. > >If we keep it, then hopefully the node that we did not place into the hash will >not be in the descendents of final move chosen by search A. > >If we overwrite it, than hopefully the node that we overwrote will not be in the >descendents of final move chosen by search A. > >Therefore, it could be a crap shoot as to whether a given descendent node is in >the hash. > >Does this make sense? > >KarinsDad :) What you could do is have a byte in your hash entries to indicate what root move the entry comes from. After a move is made, you can go through the entire table and delete the entries that don't result from that move. This isn't a perfect solution because it ignores the possibility of transpositions, but I can't see a good way to avoid this problem. I'm not even sure a scheme like this would be worth the trouble. Another thing you could do is say that if a hash probe is successful, update the counter of that hash table entry so it's from the current search. That seems like a good idea... -Tom
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.