Boost logo

Boost :

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:
> 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.

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, gregod at, cpdaniel at, john at