Author: Dann Corbit
Date: 15:17:14 05/14/01
Go up one level in this thread
On May 14, 2001 at 17:03:27, Alex Boby wrote: > As a hash replacement scheme I have 2 tables, one replace all collisions, the >other only if the depth is greater (or equal but better type). > > After a bunch of games in a row, it seems that the latter table gets full up >and is rendered more or less useless. So I think I need more flexibility for the >replacement. I considered adding a 'staleness' value so that the records are >replaced after N failed attempts. But I have no idea what I should set N to and >I'm not really fond of this idea anyways. > > I'm now thinking about just clearing the second hash table after every game. >Is this an effective strategy? It's a function of how big your hash table is, and how long your time control is. If it contains only thousands of entries, you should clear it after ever move (if at long time control). If it contains millions of entries you should clear it after every game. If it contains trillions of entries, you won't have to clear it at all[1]. The hash table does not fill up in a linear way over time, because you search for best paths. [1] OK, eventually. But it would take quite a while and would be an effective (if expensive) way of learning. If you do have a sure collision, then save the deep one and store the collision in a secondary table of size log(original_table_size). If you have a collision in the secondary table, store it in a tertiary table of size log(secondary_table_size). If you still have collisions that can't be handled, then probably something is wrong with your hash or your original hash table is way too small. Now, all of this advice is rather stupid because nobody does it that way. But I still think it's a good idea.
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.