At first glance, that the failure code only sees "two" things when it
should see "eight" seems to be problematic.
Perhaps the primitive insists on hashing byte objects, and there is a
distinction between "byte" objects and "word" objects (whatever "word"
means, presumably a constant width integer across all platforms). I
haven't looked at the code.
From my perspective... back in the day that primitive used to hash
bytes, and from what I saw here the failure code is hashing multi-byte
things. If all of these observations are correct, then I'd say the
failure code isn't doing what the primitive is doing, and in doing so
it's introducing a lot of collisions that I'd like to believe the
intended hash function wouldn't produce.
Andres.
On 12/18/16 23:05 , Martin McClure wrote:
On 12/18/2016 02:29 AM, Andres Valloud wrote:
The primitive and the primitive failure code should behave the same?
You think the primitive is faulty? I haven't looked at the primitive
code, but it just fails when given a Float. From the name, I'd guess
that it's designed for a byte object. The failure code certainly is.
A new primitive designed for word objects, or new code such as I gave
earlier (though ugly) would work, though.
Regards,
-Martin
