Re: [boost] Re: is_nan

From: gmelquio_at_[hidden]
Date: 2003-07-25 14:49:59

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

[snip]

> |  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.
> 
> The point of my mail was that it is a mistake to ignore sNaNs.

It seems there is a misunderstanding. In the context of the interval library,
think about this function as an internal function. If quiet NaNs are available,
the library will use them. And this function is here to detect them. It is meant
to detect values created by the library itself. The library only creates quiet
NaNs, the function only has to detect quiet NaNs. The library does not create
signaling NaNs, it is not necessary to have an overly complex function in order
to detect them (since this function will never have a signaling NaN as an argument).

[snip]

> | 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".
> 
> this:
> 
> | 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.
> 
> I guess, the point of my question got lost in rhetorics.  Sigh.
> 
> Ths point was the isnan() query should *not* trigger a trap.

The way the library uses it, the isnan function can not trigger a trap unless
the user messed with something. Moreover, it is a private function, the user is
not supposed to use it.

On a more general side, please keep in mind that *signaling* NaNs are meant to
trap when used ("used" can be a simple copy, the standard leaves it
implementation-defined). If the user suddenly decides to put a signaling NaN in
a floating-point variable, she shouldn't be surprised if the program traps as
soon as it uses this variable. I don't understand why the interval library
should prevent such a behavior, since it is the expected behavior (the isnan
function is an internal function used by the other functions of the library,
they are supposed to trap if supplied with a signaling value).

Regards,

Guillaume