[EMAIL PROTECTED] writes: | Sorry for the late reply, I was enjoying some peaceful holidays.
There is no reason for sorrying. | En réponse à Gabriel Dos Reis <[EMAIL PROTECTED]>: | | > Guillaume Melquiond <[EMAIL PROTECTED]> writes: | > | > | On Fri, 4 Jul 2003, Fernando Cacciola wrote: | > | | > | > Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in message | > | > news:[EMAIL PROTECTED] | > | > > "jvd" <[EMAIL PROTECTED]> 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? Do you have evidence otherwise? Must we quibble? | 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. | > | > > | } | > | > > | | > | > > | 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]. Don't worry, I have a copy of it. Not just because, something get deprecated means it gets (1) illegal, (2) out of circulation. In fact, it is still there. | Signaling NaNs are on their way to be deprecated (the §N proposal for example), I know of the proposal -- and of an initial sent to many forums. | or at least declared stricly optional (the current draft). So I wouldn't expect | a "portable" program to use signaling NaNs. Portable programs don't rely on IEEE-754 semantics. Period. So, you cannot use porability argument for discrimination. And sNaNs are still in use. *You* (Guillaume) can choose to not support them, but that is a different story. | 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. -- Gaby _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost