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.
http://blogs.msdn.com/ericflee/archive/2004/06/10/152852.aspx http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm...
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!). John.