Boost logo

Boost :

From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2003-07-25 13:14:21


gmelquio_at_[hidden] writes:

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

There is no reason for sorrying.

| 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?

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk