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

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2005-12-01 13:38:22

| -----Original Message-----
| From: boost-bounces_at_[hidden] 
| [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
| Sent: 01 December 2005 13:29
| To: Boost mailing list; boost-testing
| Subject: [boost] [math] floating point classification - 
| testing help wanted
| 
| For a while now I've been meaning to clean up my floating-point 
| classification code to provide a more reliable way of testing 
| for Nan's and 
| infinities.
| 
| 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.

Absolutely!

| Please build the test program with optimisations turned on: 
| many compilers 
| make non-IEEE arithmetic assumptions once you tell them to 
| optimise the code.

Ran thus on MS V 8.0  MSVC version 140050215
In release mode 

Had to enable C++ exceptions thus

Yes With SEH Exceptions (/EHa)

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));

I added

#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 ;-)

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.

From

http://babbage.cs.qc.edu/IEEE-754/IEEE-754references.html#kevin_chart

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

And what about _isnan(float)? It seems to pass the test but ...

as only _isnan(double) is defined - as for _nextafter :-((. (Sloth at MS!)

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.

If (or when) copysign is implemented, we can check whether -zero really is
negative.

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.

HTH

Paul

-- 
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
Phone and SMS text [phone], Mobile and SMS text [phone]
mailto: pbristow_at_[hidden]  http://www.hetp.u-net.com/index.html
http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html