> From: Lee Iverson [mailto:[EMAIL PROTECTED]]
>
> 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.
>
I think Classpath just does a truncation. It doesn't matter what you do, if
your table is 100 entries wide and you have 101 objects, you're going to
have "conflicts." If there was a "favoritism" for a single slot in the hash
table, then there would be a problem. But none of the algorithms I've come
across have that favoritism (this includes hash code), hence no need for
randomization.
--John Keiser
> ------------------------------------------------------------------
> -------------
> Lee Iverson SRI International
> [EMAIL PROTECTED] 333 Ravenswood Ave., Menlo
> Park CA 94025
> http://www.ai.sri.com/~leei/ (650) 859-3307
>
>
