Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!decvax!cca!ima!inmet!andrew
From: andrew@inmet.UUCP
Newsgroups: net.general
Subject: Re: Hash table size selection - (nf)
Message-ID: <894@inmet.UUCP>
Date: Wed, 15-Feb-84 05:50:50 EST
Article-I.D.: inmet.894
Posted: Wed Feb 15 05:50:50 1984
Date-Received: Sat, 18-Feb-84 00:52:54 EST
Lines: 19

#R:proper:-99700:inmet:4100027:000:868
inmet!andrew    Feb 14 10:57:00 1984

Yes.. it relates to double hashing, where a second hash function is used for
resolution of collisions:  If slot f1(x) is already occupied, compute a new
hash address ((f1(x)+f2(x)) mod tablesize) and try that, repeating this until
a) a vacant slot is found, or b) you return to the original f1(x), in which
case the table is effectively full.  

Case b) above will occur after (tablesize/GCD(tablesize, f2(x)) iterations;
this number is maximized when tablesize and f2(x) are relatively prime (GCD =
1).  The easiest way to ensure this for all values of f2(x) is to select a 
prime number for tablesize.

If f2(x) is a constant (degenerate double hashing), tablesize need only be
relatively prime to it; for example, a table size of 46 would be acceptable
in conjunction with a constant f2 of 9.
 
Andrew W. Rogers, Intermetrics    ...{harpo|ima|esquire}!inmet!andrew