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