Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Efficient hash algorithm?

Author: Dan Newman

Date: 17:07:02 09/21/98

Go up one level in this thread


On September 21, 1998 at 19:45:21, José de Jesús García Ruvalcaba wrote:

>On September 21, 1998 at 19:35:39, William H Rogers wrote:
>
>>On September 21, 1998 at 18:56:46, John Coffey wrote:
>>
>>>On September 21, 1998 at 18:12:36, Tom Kerrigan wrote:
>>>
>>>>Mostly correct, although maintaining two numbers to describe the position is
>>>>overkill. One 64 bit number should be enough.
>>>>
>>>
>>>Is one 64 bit number enough to uniquely identify a position?  Does this
>>>prevent two positions from getting the same hash key?
>>>
>>>I assume that you convert your hash key into an index into the history.
>>>I assume that you take your 64 bit number and divide it by a constant
>>>(or right shift it) to get the number of entries available in your hash
>>>table?  i.e. 64 megs would be 4 million positions.
>>>
>>>John Coffey
>>
>>That is why I suggested a smaller hash key of only 16 bits. That gives you 64K
>>which is a lot for a smaller program. Think about it 64 thousand opening book
>>replys. But the other boy are correct, if you have the space.
>
>	What has to do the opening book with the hash tables? Are the opening book
>positions stored in the hash tables somehow, at the beggining of the game?

What I (and others) do is store information about positions (as opposed to
moves) in an opening book file.  For each position in the book we store
the position hash code of that position (the same one used with the hash
table) along with some extra information used in making a book move
selection (win,loss,draw counts, learning info, whatever).  Typically the
positions in the file are sorted or clustered in some way by their hash
codes to make lookup faster.

-Dan.



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.