Author: J. Wesley Cleveland
Date: 17:03:21 04/12/00
Go up one level in this thread
On April 12, 2000 at 18:29:17, KarinsDad wrote: >On April 12, 2000 at 16:05:33, Tom Kerrigan wrote: > >[snip] >> >>I have a byte in my hash table entries to indicate what type of score the entry >>is (alpha, beta, pv). That only takes 2 bits, so i use the remaining 6 bits for >>a counter. So the counter can go to 64. >> >>I figure if an entry is lucky enough to avoid being clobbered for 64 searches, >>it deserves to stick around for one more. :) >> >>I usually set my general hash table size to 16MB. I have 128MB RAM, but I like >>to be able to just fire up my program with no swapping. I have no idea how fast >>I "burn" entries. Maybe I'll test that later on. >> >>-Tom > > >What I would like to do is maintain entries in the hash that are still derived >from the current 0 ply node as opposed to entries that were not discovered in >the search off of the current 0 ply node. > >For example (without an opening book): > >Counter = 1 > >1. d4 the position after 1 ... d5 2. c4 Nf6 is in the hash and has a 1 counter > > >d4 move made, Counter now = 2 > >1. ... Nf6 the position 2. c4 d5 is a transposition in the hash, but has a 1 >counter, so it may be overwritten since it's counter is not 2. > > >This seems to imply that you randomly get rid of nodes, even though they are >descendents of the current position (and in fact were found in the previous >search of the parent of the current position). > > >I'm trying to think up a way to avoid this. For example: > > >a b c d > \ / \ / > e f > \ / > g h > \ / > i > >Node c is a descendent of i. If we make move g, it is still a descendent of g, >hence, it would be nice to not get rid of it since there is still a good chance >of transpositions from it later on. However, if we make move h, it may be a >descendent of h, or it may not, but who knows? Hence, if we make move h, I would >not mind getting rid of c. > >I want to also take this idea farther based on the PV. The lower your ancestor >deviated from the PV on the tree, the more I do not care if I drop you from the >hash table. > >I cannot think of how to use your counter method to accomplish this, but your >counter method can be used as a backup check (i.e. if I am currently creating >counter 7 nodes, I probably do not care as much about counter 2 nodes as much as >counter 5 nodes). > An idea I had is: If a hash entry gives a useful value, set the counter in the entry to the current. This should
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.