Boost logo

Boost :

From: John Maddock (john_at_[hidden])
Date: 2005-12-02 05:58:13

> I think it isn't too hard to implement this for x86 by looking at the
> binary representation - would you be interested? I was experimenting
> with doing something like that, but decided not to, as it doesn't
> really matter what hash value you generate for a NaN and I was
> worried about
> missing some special case. Whenever I think I fully understand
> floating point, something new always crops up.

Doesn't it just :-)

At present it looks like only VC6 signaling nan's are broken, I was hoping
to avoid non-portable binary-extraction if possible, but it wouldn't be too
much of a hardship to support x86.

>> Suse Linux:
>> gcc-3.3.3 : OK.
> IIRC, gcc-2.95 doesn't have fpclassify, but it might be possible to
> implement it with other functions.

I'll test with that when I get a chance: the whole point of the test code is
that it doesn't require fpclassify, but will use it if present.

> Oh, I've been using _fpclass for hash (not checked into CVS yet) -
> which suggests that my tests are lacking something. Is this something
> I should
> be worried about?

It depends if you want to detect non-nan's correctly: a float converted to
double may become normal when it was subnormal before.

> On Visual C++ a long double has the same representation as a double
> so I think it should work for that case at least.
> Incidently, I'm not sure, but I think other x86 compilers have a
> different 80 bit long double to the one described in the msdn page.

Yes, they have a 10-byte long double, in that case long-double to double
convertions may change the value's category:

normal -> infinity
sub-normal -> zero
normal -> sub-normal

It doesn't affect whether it's a NaN or not though, so you can use _isnan
safely (except for the broken VC6 version that is!).


Boost list run by bdawes at, gregod at, cpdaniel at, john at