## digitalmars.D - nan or -nan?

• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (22/22) Nov 15 2011 Some floating point operations produce .nan:
• Iain Buclaw (10/32) Nov 17 2011 n
• bearophile (5/9) Nov 17 2011 It's a NaN, but floating point designers have given a sign to NaNs for a...
• Walter Bright (2/3) Nov 17 2011 What is that purpose?
• bearophile (4/8) Nov 17 2011 I didn't know the answer, so I've done a short research (finding texts l...
• Walter Bright (7/20) Nov 17 2011 There is a NaN "payload" in the significand which it is polite to preser...
• Paul D. Anderson (8/32) Nov 18 2011 From the Decimal Arithmetic Specification (http://speleotrove.com/decima...
• Walter Bright (7/16) Nov 18 2011 Signaling vs quiet is not set by the sign bit, but by the most significa...
• Don (9/22) Nov 21 2011 I'm not sure about that. They may simply be saying that it has no
• Iain Buclaw (7/10) Nov 18 2011 When I said libraries, I meant system libraries - ie: glibc. I seem to
=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
```Some floating point operations produce .nan:

import std.stdio;

void main()
{
double zero = 0;
double infinity = double.infinity;

writeln("any expression with nan: ", double.nan + 1);
writeln("    zero / zero        : ", zero / zero);
writeln("    zero x infinity    : ", zero * infinity);
writeln("infinity / infinity    : ", infinity / infinity);
writeln("infinity - infinity    : ", infinity - infinity);
}

Last time I checked, I think the program above would produce nan for all
of those operations. Now some are -nan when compiled with 64-bit dmd
2.056 on Linux:

any expression with nan: nan
zero / zero        : -nan
zero x infinity    : -nan
infinity / infinity    : -nan
infinity - infinity    : -nan

Is that expected? Does it matter?

Ali
```
Nov 15 2011
Iain Buclaw <ibuclaw ubuntu.com> writes:
```On 16 November 2011 04:35, Ali =C7ehreli <acehreli yahoo.com> wrote:
Some floating point operations produce .nan:

import std.stdio;

void main()
{
=A0 =A0double zero =3D 0;
=A0 =A0double infinity =3D double.infinity;

=A0 =A0writeln("any expression with nan: ", double.nan + 1);
=A0 =A0writeln(" =A0 =A0zero / zero =A0 =A0 =A0 =A0: ", zero / zero);
=A0 =A0writeln(" =A0 =A0zero x infinity =A0 =A0: ", zero * infinity);
=A0 =A0writeln("infinity / infinity =A0 =A0: ", infinity / infinity);
=A0 =A0writeln("infinity - infinity =A0 =A0: ", infinity - infinity);
}

Last time I checked, I think the program above would produce nan for all =

of
those operations. Now some are -nan when compiled with 64-bit dmd 2.056 o=

n
Linux:

any expression with nan: nan
=A0 =A0zero / zero =A0 =A0 =A0 =A0: -nan
=A0 =A0zero x infinity =A0 =A0: -nan
infinity / infinity =A0 =A0: -nan
infinity - infinity =A0 =A0: -nan

Is that expected? Does it matter?

Ali

This behaviour may be due to the libraries rather than the compiler.
But whether the bit that controls signed-ness is on or off, doesn't
stop the value being NaN.  So I would not give much concern to the
result.

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
```
Nov 17 2011
bearophile <bearophileHUGS lycos.com> writes:
```Iain Buclaw:

This behaviour may be due to the libraries rather than the compiler.

In any case there is a bug to be found an fixed.

But whether the bit that controls signed-ness is on or off, doesn't
stop the value being NaN.  So I would not give much concern to the
result.

It's a NaN, but floating point designers have given a sign to NaNs for a
(small) purpose. In a numerics-oriented language as D you don't want to ignore
that purpose, you want to get right the full semantics of floating point
numbers, on 64 bits too. So I suggest to add this problem in Bugzilla.

Bye,
bearophile
```
Nov 17 2011
Walter Bright <newshound2 digitalmars.com> writes:
```On 11/17/2011 3:57 PM, bearophile wrote:
It's a NaN, but floating point designers have given a sign to NaNs for a
(small) purpose.

What is that purpose?
```
Nov 17 2011
bearophile <bearophileHUGS lycos.com> writes:
```Walter:

On 11/17/2011 3:57 PM, bearophile wrote:
It's a NaN, but floating point designers have given a sign to NaNs for a
(small) purpose.

What is that purpose?

I didn't know the answer, so I've done a short research (finding texts like
this: http://grouper.ieee.org/groups/754/email/msg03893.html ), I have found
that languages usually ignore the sign of the NaNs (while the sign of zero has
some purposes). Producing the same bit patterns for 32 and 64 bit compilers is
useful for output binary consistency for comparisons, but comparing floating
point values bitwise is usually a not so wise thing to do. So I think there is
no need to put this in Bugzilla.

Thank you for your question, bye,
bearophile
```
Nov 17 2011
Walter Bright <newshound2 digitalmars.com> writes:
```On 11/17/2011 5:29 PM, bearophile wrote:
Walter:

On 11/17/2011 3:57 PM, bearophile wrote:
It's a NaN, but floating point designers have given a sign to NaNs for a
(small) purpose.

What is that purpose?

I didn't know the answer, so I've done a short research (finding texts like
this: http://grouper.ieee.org/groups/754/email/msg03893.html ), I have found
that languages usually ignore the sign of the NaNs (while the sign of zero
has some purposes). Producing the same bit patterns for 32 and 64 bit
compilers is useful for output binary consistency for comparisons, but
comparing floating point values bitwise is usually a not so wise thing to do.
So I think there is no need to put this in Bugzilla.

There is a NaN "payload" in the significand which it is polite to preserve,
though no program has ever been observed to make use of it. The sign bit is not
part of the payload. Requiring preservation of the sign bit means that one
could
not negate a floating point value without checking for NaN, which would be a
significant performance penalty.

It's not a bug.
```
Nov 17 2011
Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
```Walter Bright Wrote:

On 11/17/2011 5:29 PM, bearophile wrote:
Walter:

On 11/17/2011 3:57 PM, bearophile wrote:
It's a NaN, but floating point designers have given a sign to NaNs for a
(small) purpose.

What is that purpose?

I didn't know the answer, so I've done a short research (finding texts like
this: http://grouper.ieee.org/groups/754/email/msg03893.html ), I have found
that languages usually ignore the sign of the NaNs (while the sign of zero
has some purposes). Producing the same bit patterns for 32 and 64 bit
compilers is useful for output binary consistency for comparisons, but
comparing floating point values bitwise is usually a not so wise thing to do.
So I think there is no need to put this in Bugzilla.

There is a NaN "payload" in the significand which it is polite to preserve,
though no program has ever been observed to make use of it. The sign bit is
not
part of the payload. Requiring preservation of the sign bit means that one
could
not negate a floating point value without checking for NaN, which would be a
significant performance penalty.

It's not a bug.

From the Decimal Arithmetic Specification
(http://speleotrove.com/decimal/decarith.pdf):

"All special values may have a sign, as for finite numbers. The sign of an
infinity is significant (that is, it is possible to have both positive and
negative infinity), and the sign of a NaN has no meaning, although it may be
considered part of the diagnostic information."

In addition, the specification, based on IEEE 754 and IEEE 854, makes a
distinction between a "signaling NaN" (sNaN) and a "quiet NaN" (qNaN). D
doesn't make this distinction. In essence all D NaNs are signaling.

The specification includes the quiet NaN for "a value representing undefined
results... which does not cause an Invalid operation condition". In practice,
this is the result of an arithmetic operation with a NaN (quiet or signaling)
as an operand. (An sNaN as an operand will still raise an invalid operation
flag, but if this doesn't cause an exception, the result of the operation will
be a qNaN.)

I don't know if this will be of any more value than the NaN payload, but there
it is.

Paul

p.s.
```
Nov 18 2011
Walter Bright <newshound2 digitalmars.com> writes:
```On 11/18/2011 1:32 PM, Paul D. Anderson wrote:
From the Decimal Arithmetic Specification
(http://speleotrove.com/decimal/decarith.pdf):

"All special values may have a sign, as for finite numbers. The sign of an
infinity is significant (that is, it is possible to have both positive and
negative infinity), and the sign of a NaN has no meaning, although it may be
considered part of the diagnostic information."

Having no meaning means it is legitimate to not be concerned if the sign is
toggled.

In addition, the specification, based on IEEE 754 and IEEE 854, makes a
distinction between a "signaling NaN" (sNaN) and a "quiet NaN" (qNaN). D
doesn't make this distinction. In essence all D NaNs are signaling.

Signaling vs quiet is not set by the sign bit, but by the most significant bit
of the significand. D does make use of signaling NaNs as they are what are
generated for uninitialized data.

Other than that, the payloads are not used. I did support them in Digital Mars
C, but nobody used them.
```
Nov 18 2011
Don <nospam nospam.com> writes:
```On 19.11.2011 01:22, Walter Bright wrote:
On 11/18/2011 1:32 PM, Paul D. Anderson wrote:
From the Decimal Arithmetic Specification
(http://speleotrove.com/decimal/decarith.pdf):

"All special values may have a sign, as for finite numbers. The sign
of an
infinity is significant (that is, it is possible to have both positive
and
negative infinity), and the sign of a NaN has no meaning, although it
may be
considered part of the diagnostic information."

Having no meaning means it is legitimate to not be concerned if the sign
is toggled.

I'm not sure about that. They may simply be saying that it has no
"physical" meaning, without saying that it has no meaningful semantics.
The behaviour is a bit strange, because x86 does define the sign of NaN
for all operations.

If the sign doesn't have reliable semantics, we probably shouldn't be
printing it. It just causes confusion. Personally, I think it would make
more sense to only print the sign if you're also printing the payload.
Maybe print -nan for %a format, but not for %f and %e.
```
Nov 21 2011
Iain Buclaw <ibuclaw ubuntu.com> writes:
```On 17 November 2011 23:57, bearophile <bearophileHUGS lycos.com> wrote:
Iain Buclaw:

This behaviour may be due to the libraries rather than the compiler.

In any case there is a bug to be found an fixed.

When I said libraries, I meant system libraries - ie: glibc. I seem to
recall it being added a few years back.  If you are on an older
system, or Windows, you may not see the signedness at all.

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
```
Nov 18 2011
=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
```On 11/18/2011 11:54 AM, Iain Buclaw wrote:
On 17 November 2011 23:57, bearophile<bearophileHUGS lycos.com>  wrote:
Iain Buclaw:

This behaviour may be due to the libraries rather than the compiler.

In any case there is a bug to be found an fixed.

When I said libraries, I meant system libraries - ie: glibc. I seem to
recall it being added a few years back.  If you are on an older
system, or Windows, you may not see the signedness at all.

That makes sense: I've moved from CentOS 4 to Ubuntu 11.

Ali
```
Nov 18 2011