On 26/02/2010 19:24, Ian Lance Taylor wrote:
> Paolo Carlini <paolo.carl...@oracle> writes:
>
>> I'm trying to simplify somewhat code in the library hashing floating
>> point numbers, and I would find very useful a simple "recipe" giving the
>> total number of bits actually used by a long double: the basic issue is
>> that for formats like the 80-bit Intel, I can't just rely on sizeof,
>> because the last 6 bytes are unused. At the moment I'm trying to cook up
>> something fixing that count with LDBL_MANT_DIG, but maybe there is
>> something simpler, maybe using preprocessor builtins?!?
>
> I saw that this led into a long discussion which I didn't fully
> understand. I just want to comment that you can't reasonably hash
> floating point representations by simply hashing the bits, even if you
> can figure out how many bits there are. A hash function is
> necessarily tied to an equality function, and when comparing floating
> point numbers for equality some bits are ignored. In particular you
> can have multiple representations of NaN, which for most hashing
> purposes would be considered to be the same.
Heh. sprintf() them into a buffer, then hash the string representation,
which is effectively normalised. Use only a limited number of digits of
precision because for a hash table false matches are fine, only false
negatives matter. Of course the sprintf overhead would kill all the
advantages of having a hash table. Maybe there's some other, cheaper "cheap
trick" that could be used to normalise FP representations into something more
easily hashable.
At the very least, it sounds like hash-aux.cc should be fpclassify()ing its
inputs, using the bits of the result from that as part of the hash tag, and
only ever including bits from the actual fp operand for FP_NORMAL and
FP_SUBNORMAL types. You might or might not want to hash in the sign bit as
well to distinguish infinities.
cheers,
DaveK
