Author: Dieter Buerssner
Date: 06:45:31 09/15/00
Go up one level in this thread
On September 15, 2000 at 08:30:10, Jan Pernicka wrote: > Hi, >as I'm just fighting with hash tables in my program, my question is about it. > >Descriprion: My hash table(s) (HT) are in fact two: one for positions, where > white is on move and one where black is on move. This works OK > but... >Problem: It's clear that one table will be much more occupied than second one > (because when you sketch the tree of the game to some depth (IE these > are positons possibly saved to HT) and label it's nodes as "white to > move" or "black to move", then one kind of them will be in greater > majority. So my model of HT is inefficient. >Solution: 1) To have only one HT and with each saved position have a flag > indicating side to move. > 2) To have (also) one HT and evry hashed positon (IE: that 32-bit > number in HT...) XOR with some (32-bit) constant depending on side > to move. I use some sort of compromise of the above. From a 64 hashkey, I use 32 to calculate an index into the hash table. The other 32 bits are shifted one to the left and have the side to move as the lowest bit. The 32bits are used, to verify the position. I think this is about as fast, as it can get, and won't have the disadvantage of unsymmetrical filling and the need to maintain two tables. - Dieter
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.