Re: [Boost-users] A proposal to make float_hash_value<> more portable

From: Daniel Krügler (dsp_at_[hidden])
Date: 2005-08-23 01:12:53

Daniel James wrote:
> Daniel Krügler wrote:
> 
>>To my opinion boost itself provides a simple helper class, namely
>>static_log2, which allows the correct implementation by using the
>>extended formular
>>
>>#include <boost/integer/static_log2.hpp>
>>....
>>std::size_t const length
>>                  = (std::numeric_limits<T>::digits *
>>                          boost::static_log2<std::numeric_limits<T
>>                             >::radix>::value +
>>                          std::numeric_limits<int>::digits - 1)
>>                  / std::numeric_limits<int>::digits;
>>
>>Note that the expression
>>boost::static_log2<std::numeric_limits<T>::radix>::value is exactly 1
>>in the usual base-2 case, but e.g. 4 in case of base-16.
>>
>>My proposed fix is exact in all cases, where radix is a power of 2, in
>>other cases (like base-10) it would at least be a better approximation
>>than the current one.
> 
> 
> Thanks for letting me know, I need to think about this. It the radix 
> isn't a power of 2, then I guess that frexp and ldexp will be slow and 
> inaccurate. Maybe ldexp could be replaced with a multiplication.
> 
> As it is, I'm not happy with the current implementation. It might be 
> better to print the float to a string and then generate a hash value 
> from that. That's not great, but it might be more portable.

I don't think, that stringifying floats to perform its hashing is really
the better solution. Besides the performance issues this method is also
not strictly portable, because the length of the string would depend on
std::numeric_limits::digits10.

One of the (minor) shortcomings of the current impl (although not for
everyone) is that non-normal floats like infinities and NaNs (if they
exist) all return the same value like 0. Having some of the new C99
floating-point diagnosis functions available (fpclassify is your
friend), one could create discriminating values for at least these
categories (not for individuals of those).

Besides these and the originally described base issue I don't see any
problems of your current implementation, I really don't see any reason
for absolute portability.

Daniel