[boost] Re: Proposal: Interval arithmetic library

From: Maarten Keijzer (mak_at_[hidden])
Date: 2000-03-08 04:48:56

>I've changed that, since it does not seem to make a difference
>on Linux/gcc.  I wonder whether
>_isnan(std::numeric_limits<double>::signaling_NaN())
>returns "false" with MSVC. This would not be the expected behavior.

In fact, just checked it and it does! So signaling_NaN is not a NaN value
according to MSVC's _isnan(). There also exists a function called
_fpclass() that gives an integer back indicating the type of float.
Checking numeric_limits::signaling_NaN() against the return value of
_fpclass() indicates that MSVC's signaling_NaN() is not a signaling_NaN at
all, it *is* negative infinity! Scrambling through the header and help
files some more indicates that MSVC's C-runtime library does not have a
stored representation for signaling_NaN, maybe this causes the error in
numeric_limits.

For what its worth (given the implementation of MSVC's float support),
their help file states about NaN's that:

o Quiet NaNs represent unknown or uninitialized values.

o Signaling NaNs represent symbolic values and values that are too big or
too precise for the format. Signaling NaNs raise an invalid operation
exception whenever an operation is attempted on them. 

So I guess that for the purposes of the interval library quiet_NaN() is the
one we need. 

(and just as a sidenote: I found this strange behaviour as
interval_test.cpp checks sqrt in the range [-1,2]. All sqrts on this range
give NaN's as they should, but I don't think this is a proper test of sqrt,
maybe add another test for the range [0, 2]?)

Well, sorting out this nightmare at least gives me an idea of where to hunt
down this bug that has been bugging me for a few weeks now!

-Maarten-

******************************************
Maarten Keijzer

DHI Water & Environment

Agern Allé 11
DK-2970  Hørsholm
Denmark
Phone: [phone]
Direct phone: [phone]
Fax: [phone] 
email: mak_at_[hidden]
******************************************