En réponse à Gabriel Dos Reis <[EMAIL PROTECTED]>: [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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost