Re: [boost] [math] floating point classification - testing help wanted

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.

http://blogs.msdn.com/ericflee/archive/2004/06/10/152852.aspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/impdf_25.asp

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