John Maddock wrote:
The new TR1 complex number code could really use this to improved it's reliability. I believe Robert Ramey was looking for this functionality for serialisation, and frankly it's hard to write any serious floating point code without it.
I'm using it for hashing floating point numbers so I'm very interested. I'll look at it in detail this weekend.
Tested so far:
Win32: VC6: Can't detect signaling NaN's (_isnan is broken).
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.
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.
#elif defined(_MSC_VER) // This only works for type double, for both float // and long double it gives misleading answers. int fpclassify BOOST_NO_MACRO_EXPAND(double t) { switch(::_fpclass(t))
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? 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. Daniel