At Wed, 16 Nov 2011 13:58:26 +0800,
Liu Yuan wrote:
>
> On 11/16/2011 01:50 PM, MORITA Kazutaka wrote:
>
> >>>
> >>> We already have a hash function, fnv_64a_buf(). How about using it
> >>> instead of introducing new one?
> >>>
> >>
> >>
> >> When I need a hash function that inputs an integer and outputs an
> >> integer for specified bits, I looked at the fnv_64a_buf(), it seems to
> >> me it tries to hash an string to integer. So I think these hash
> >> functions do a different thing, no?
> >
> > We already use it to calculate a hash value from a 64 bit object id:
> >
> > fnv_64a_buf(&oid, sizeof(uint64_t), FNV1A_64_INIT);
> >
> > I guess this generates a less random value than hash_64(), though.
>
>
> Umm, I didn't go over usage close enough, and this interface is more
> named to handle string hash, at least to me.
>
> So even we use it to hash integer, we need to further bit operation to
> remove extra bits. hash_long(hval, bits) has a nicer and more intuitive
> interface to handle integer.
static inline uint64_t hash_64(uint64_t val, unsigned int bits)
{
uint64_t hash = fnv_64a_buf(&val, sizeof(uint64_t), FNV1A_64_INIT);
return hash >> (64 - bits);
}
Isn't this good for you?
>
> How about coexisting these two? fnv_64a_buf() is supposed to handle
> string hash and hash_long() is supposed to handle integer otherwise.
If you need a better randomized function for integers, I'm not against
introducing a new hash. But otherwise, FNV hash looks enough to me.
Thanks,
Kazutaka
|
|