I don't think implementors will do such a thing like val%table_size.
They can as well try to do a simple operation like
(val & MAXINT)%table_size
to reduce such problems to some extent.
--
ramky
At 05:15 PM 10/19/98 -0700, Lee Iverson wrote:
>In message <000201bdfbc6$428d6120$LocalHost@template> you write:
>> The hashtable knows this. It's not a direct mapping of hash code to value
>> ... it's hash code to a linked list of values with the same hash code.
>> Hashtables are normally implemented this way, actually, and in a normal
>> hashtable implementation you will have a lot of different hashcodes sharing
>> the same linked list.
>
>Fair enough, but how and where is the index into the hash table
>determined? If it's just a truncation (val%table_size) then you
>should see real problems with object locality causing hash table
>conflicts (i.e. linked lists with non-unit length). Knuth recommends
>a 32-bit unsigned multiply by 2654435769U (a very simple
>pseudo-randomizer) before the modulus to table size.
>
>-------------------------------------------------------------------------------
>Lee Iverson SRI International
>[EMAIL PROTECTED] 333 Ravenswood Ave., Menlo Park CA 94025
>http://www.ai.sri.com/~leei/ (650) 859-3307
>
