Re: [boost] Re: is_nan

From: gmelquio_at_[hidden]
Date: 2003-07-25 12:19:31

Sorry for the late reply, I was enjoying some peaceful holidays.

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

> Guillaume Melquiond <gmelquio_at_[hidden]> writes:
> 
> | On Fri, 4 Jul 2003, Fernando Cacciola wrote:
> | 
> | > Gabriel Dos Reis <gdr_at_[hidden]> wrote in message
> | > news:m31xx6i7tm.fsf_at_uniton.integrable-solutions.net...
> | > > "jvd" <vygis_d_at_[hidden]> writes:
> | > >
> | > > | Dear boosters,
> | > > |
> | > > | seems like this code
> | > > |
> | > > |     template< typename T >
> | > > |     bool is_nan( const T& v )
> | > > |     {
> | > > |         return std::numeric_limits<T>::has_quiet_NaN && (v != v);

Do you read the previous line? We are speaking about quiet NaNs here. And so I
was justifying why the interval library computes "v != v" in order to detect
quiet NaNs. I never intended to speak about signaling NaNs.

> | > > |     }
> | > > |
> | > > | does not work correctly on some machines.
> | > >
> | > > Yes.  It is an incorrect (unfortunately popular) implementation.
> | > >
> | > Right. We should say that more often. It is incorrect however popular.
> | 
> | Yes, it is incorrect for C++. But it's something we can hope to see one
> | day. For example, in the LIA-1 annex I about C langage bindings, it is
> | written that != is a binding for IEEE-754 ?<> operator (unordered
> | compare). In the C9X annex F.8.3 about relational operators, it is written
> | that the optimization "x != x -> false" is not allowed since "The
> | statement x != x is true if x is a NaN". And so on.
> 
> You seem to forget that C99 does not consider Signalling NaNs -- which
> are other missing parts of C99.  For those NaNs, the comparaison might
> just trap.
> 
> Please, be careful when quoting.

I hope you understand I was careful when quoting: we only were talking about
quiet NaNs initially. But since you absolutely want to talk about signaling
NaNs, I suggest you take a look at the revision of the IEEE-754 standard[1].
Signaling NaNs are on their way to be deprecated (the §N proposal for example),
or at least declared stricly optional (the current draft). So I wouldn't expect
a "portable" program to use signaling NaNs.

As for your other mail:

> From your above statement,  I understand that the interval library
> does not use sNaNs by itself.  What about users getting sNaNs with the
> library? 

I don't understand what you mean by "getting sNaNs with the library". When using
intervals with floating-point bounds, the library only uses floating-point
operations and so it will never produce signaling NaNs. It won't even use
floating-point operations that would produce quiet NaNs. For example, '0/0' will
never be computed. Such a behavior would break the library when used with other
kinds of intervals (integer bounds for example).

If the user gives signaling NaNs in input, the interval program will fail
exactly as if it was a floating-point program: it will generate a floating-point
trap. It is the responsability of the user to only provide meaningful inputs:
she should not use signaling NaNs if she doesn't provide a checking policy able
to catch them the way she want (it's what I mean by "meaningful input").

Regards,

Guillaume

[1] http://754r.ucbtest.org/