Author: Robert Hyatt
Date: 17:40:42 03/06/98
Go up one level in this thread
On March 06, 1998 at 20:18:51, Will Singleton wrote: >I'm having trouble getting transposition tables to work in my program. >Part of the problem is the spaghetti code, but I'd like to make sure I >understand the basics before going further. Any comments would be >appreciated. > >The following has been taken from various publications and source code: > >I generate an array of random numbers that are associated with each >piece-square combination. The array is 12 * 64 entries, 32-bit uints. >The array is referenced by rand_num = rand_array [piece][square]. Then >all the values are XOR'd together to get the hash_key, using only the >occupied squares. Other random nums are used to represent ep_status and >castling. first thing to look at is 32 bits is not enough. you will get way too many false matches (collisions).. enough to produce bogus results. > >The low-order 18 bits of the 32-bit key are used to generate the index >into the hash table. Store the hash key, along with depth, score, >move#, valid_flag, and the move itself. I use two hash tables, one for >each color, each 262k entries. > >At new_game, zero the hash table, generate the hashkey, and then for >each move, update it. hashkey = (hashkey ^ from pc_sq) ^ to pc_sq. > >---- Before generating moves, probe the table ---- > >address = hashkey & 0x0003ffff; >if (tt_table [plylevel % 2][address].hashlock == hashkey) > if (table_depth >= plylevel) > see if score is true score, or upper/lower bound (from cutoff) > if true score, return > if upper/lower, compare to beta for cutoff > else try move > >---- After unmake move, store to the table ---- > >if (cutoff or bestmove) > if (tt_table depth <= plylevel) > store to the table, setting valid flag to upper/lower or true >score > >----------------------------------- > >Question: some have said that storing positions from the leaf nodes is >not so good, since it fills the table with sometimes irrelevant data. >What about that, and how about using the tables in the qsearch? > it is a near "wash". I've done it both ways. I like not storing things in q-search, because it significantly reduces hash table loading, and (for me) is a tiny bit faster in execution speed too... >Help would be appreciated, as always. I didn't see an example of what kind of problem you are having... > >Will
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.