Author: Tom Kerrigan
Date: 23:48:22 12/09/99
Go up one level in this thread
There are two sorts of collisions: (1) This is when you try to put something in the hash table but there's already something in that spot. You have to decide which entry to keep, but you can't keep both, so your program gets slower. (2) This is when you have two different positions but they happen to have the same hash key, so the program can get confused and error is introduced in the search. So if you don't have much memory, you get lots of (1) collisions, which is not good because the program runs slower. But it's not really bad, either, because it doesn't cause errors. If you search for a long time, you're bound to get more (2) collisions, which is bad because it can cause errors. (Although these errors typically aren't very significant if you're using 64 bit hash keys...) -Tom On December 09, 1999 at 16:32:14, Dann Corbit wrote: >If you only have a small amount of memory and your program calculates a long >time, you will obviously get collisions. What I am wondering is: > >"Has anyone done a careful study of the actual probability of collisions as a >function of both the number of hash slots reserved and the number of nodes >examined over time?"
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.