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