In article <··········@info-server.bbn.com> ·····@bbn.com writes:
>I think i'm getting hash collisions, which is really really bad in my
>apps (it breaks the window redisplay mechanisms, as things try to dislay
>the wrong objects).
Hash collisions can affect performance, but they shouldn't result in the
wrong object being returned. Almost all hash tables have collisions, and
all correct hash table implementations must have collision-resolution
mechanisms. I suspect collisions aren't your true problem.
>what I'm using a keys are dinky little arrays like this:
>
> #(integer integer integer)
What kind of hash table are you using -- EQL or EQUAL?
If it's an EQUAL hash table, make sure you don't modify the contents of the
array while it's in use as a hash key. The hash code is based on the
contents of the array, so changing it will change the code, and the
implementation won't be able to find the hash entry.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
Barry Margolin <······@think.com> wrote:
>> what I'm using a keys are dinky little arrays like this:
>>
>> #(integer integer integer)
>
> If it's an EQUAL hash table, make sure you don't modify the contents of the
> array while it's in use as a hash key. The hash code is based on the
> contents of the array, so changing it will change the code, and the
> implementation won't be able to find the hash entry.
I don't think an implementation is permitted to look at the contents of an
array for computing the EQL or EQUAL hash code of an object. Because EQUAL
on arrays is equivalent to EQL. After all,
(let ((v (vector 65537 15 83)))
(equal v (progn (setf (svref v 2) '19) v))
)
returns T, so the hash code of the array before modification and the hash
code of the array after modification have to be the same.
Bruno Haible
······@ma2s2.mathematik.uni-karlsruhe.de