From: Daniel James (daniel_at_[hidden])
Date: 2005-12-01 18:37:24
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:
> 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)
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk