Re: [boost] [math] floating point classification - testing helpwanted

From: John Maddock (john_at_[hidden])
Date: 2005-12-01 14:18:06

> To get a clean compile at level 4 with no MS extensions,  I had to
> patch
>
> ios_state.ipp
>
> #if defined(_MSC_VER)
> #  pragma warning( push)
> #  pragma warning(disable : 4512) // assignment operator could not be
> generated.
> #endif
>
> and #pragma (pop) at the end of the module.
>
> in test_tools.ipp added static_cast<std::streamsize>( - to avoid a
> warning)
>
> m_pimpl->m_pattern.ignore(
> static_cast<std::streamsize>(m_pimpl->m_synced_string.length() - i -
> suffix_size));

That's a Boost.Test issue.

> #if defined(_MSC_VER)
> #  pragma warning(disable : 4723) // Deliberate potential divide by 0!
> #endif
>
> at the top of classify.cpp - looks like you really you mean to do
> this ;-)

Yes :-)

> and
>
> #elif defined(_MSC_VER) || defined(__BORLANDC__)
>   if(::_isnan(static_cast<double>(t)))
>    // was if(::_isnan(t))
> // warning C4244: 'argument' : conversion from 'long double'
> to 'double', possible loss of data
> // Global isnan only REALLY works for double?
>
>      // _CRTIMP __checkReturn int    __cdecl _isnan(__in double _X);
>
>      return FP_NAN;
> #endif
>
> Is this really right?  I would expect to have to have some other code
> do deal with the long double case, not just a cast?  Or are we
> relying on MS never bothering to provide a true long double, >=80 ?
> If so, a comment would be helpful.

I'm relying on the fact that a cast to a narrower or wider type will never 
create or destroy a NaN: we may get underflow to zero, or overflow to 
infinity, but otherwise once a NaN always a NaN :-)

> The range of NaNs will be quite quite different for longer long
> doubles?

The bits are different, but a cast won't suddenly turn a NaN into something 
else.

BTW the only reason that bit of code is in there, is to guard against 
optimising compilers making non-IEEE assumptions in the rest of the code 
(and yes the compilers exist).

> And what about _isnan(float)? It seems to pass the test but ...
>
> as only _isnan(double) is defined - as for _nextafter :-((. (Sloth at
> MS!)

Indeed, that's why _fpclass can only be used for type double.

> But I note that you have only tested with two of the considerable
> range of possible NaN.
>
> FFFFFFFF  to FF800001 and 7F800001 to 7FFFFFFF for 32 bit.
>
> FFFFFFFFFFFFFFFF to FFF0000000000001 and 7FF0000000000001 to
> 7FFFFFFFFFFFFFFF for 64-bit
>
> Exhaustive testing would be exhausting, even for 32-bit, and I am not
> sure how to portably create more test values. It's really a bit
> twiddling job for vendors.

That's the problem: there is no portably way to create NaN's with other 
payloads, not even with ldexp.

> I get:
>
> Running 1 test case...
>  .\classify.cpp Thu Dec  1 18:02:20 2005
> MSVC version 140050727
> FP_ZERO: 0
> FP_NORMAL: 1
> FP_INFINITE: 2
> FP_NAN: 3
> FP_SUBNORMAL: 4
> Testing type float
> Testing type double
> Testing type long double
>
> *** No errors detected
> Press any key to continue . . .
>
> Which looks fine to me.

Good, thanks.

John.