[boost] Interval library and signaling NaNs

From: gmelquio_at_[hidden]
Date: 2003-07-27 05:58:29

En réponse à Gabriel Dos Reis <gdr_at_[hidden]>:

> Not actually.  It is an assumption he is making.  With the corollary
> that the users deserves non-sense if his assumption is not met.

This kind of statement is not really useful. Let's try to raise the level of the
discussion with some concrete facts.

Let's consider a class imitating the behavior of a type having a signaling NaN:

struct A {
  bool is_sNaN;
  A(): is_sNaN(false) {};
  A(bool v): is_sNaN(v) {};
  bool operator<=(A const &x) const {
    if (is_sNaN || x.is_sNaN) throw;
    return true;
  }
};

The program will trap if a sNaN is compared with something. The same behavior is
encountered on platforms that provide a floating-point with support for
signaling NaNs.

Now let's consider this little program:

int main() {
  boost::numeric::interval<A> x(A(false), A(true));
}

The user tries to initialize the bounds of an interval x with a normal number
A(false) and a signaling NaN A(true). If you execute the program, it will throw
(if you want to try it yourself, don't forget to add the line
#include<boost/numeric/interval.hpp> for the program to compile).

Please note that this program doesn't even have to invoke is_nan: a signaling
NaN trap simply occurs because the constructor is looking if the bounds are
ordered or not. Now I'm saying it is the expected behavior: the user created a
signaling NaN and the program trapped when the interval library tried to use
this value. The same thing would happen with floating-point numbers.

You can now explain to us why the library shouldn't have trapped although one of
the input was a signaling NaN.

Guillaume