• bearophile <bearophileHUGS lycos.com> Mar 24 2010
• Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> Mar 24 2010
• bearophile <bearophileHUGS lycos.com> Mar 24 2010
• Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> Mar 24 2010

bearophile <bearophileHUGS lycos.com> writes:

Don:
Sometimes NaNs are true, sometimes not!<


Urg.


 That won't work in this case, unless you make nan a keyword. There are 
 2^^62 different NaNs, so a bitwise comparison will not work.


You are right, I did forget that here.
So I have modified a little my request:
http://d.puremagic.com/issues/show_bug.cgi?id=3981

"x is double.init" can be used to detect uninitialized variables, because in
this proposal "is" performs a bitwise comparison (this makes "is" not that
useful with structs).

The syntax "x == nan" can be used to perform the smart comparison with all
possible nans. But this is an uncommon operation, so isnan(x) is good enough.

Bye and thank you for your insights,
bearophile

Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:

bearophile Wrote:

 Don:
Sometimes NaNs are true, sometimes not!<


 Urg.
 
 
 That won't work in this case, unless you make nan a keyword. There are 
 2^^62 different NaNs, so a bitwise comparison will not work.


 You are right, I did forget that here.
 So I have modified a little my request:
 http://d.puremagic.com/issues/show_bug.cgi?id=3981
 
 "x is double.init" can be used to detect uninitialized variables, because in
this proposal "is" performs a bitwise comparison (this makes "is" not that
useful with structs).
 
 The syntax "x == nan" can be used to perform the smart comparison with all
possible nans. But this is an uncommon operation, so isnan(x) is good enough.
 
 Bye and thank you for your insights,
 bearophile


There are a finite number of NaNs for a fixed-length floating point number, but
there are a (conceptually) infinite number for an arbitrary precision float.
The sign, coefficient and exponent are undefined for a NaN, although the
coefficient and sign fields can be used as a "payload" for the NaN, containing
diagnostic information, etc.

And, according to the General Decimal Arithmetic Specification
(http://speleotrove.com/decimal) comparing NaN with any number, including
another NaN, will never return true. The operation raises an "Invalid
Operation" exception.

Paul

bearophile <bearophileHUGS lycos.com> writes:

Paul D. Anderson:

the coefficient and sign fields can be used as a "payload" for the NaN,
containing diagnostic information, etc.<


They are the tagged NaNs. Do you know of a possible usage of them? :-)


 And, according to the General Decimal Arithmetic Specification
(http://speleotrove.com/decimal) comparing NaN with any number, including
another NaN, will never return true.<


(Note: I am not proposing of introducing "== nan" in D, that enhancement
request is just about the "is" operator).
There are situations where you want to know if a number is any NaN (or if it's
specifically the NaN used by D to initialize floats/reals/doubles). The
std.math.isNaN() function is useful.

Bye,
bearophile

Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:

bearophile Wrote:

 Paul D. Anderson:
 
the coefficient and sign fields can be used as a "payload" for the NaN,
containing diagnostic information, etc.<


 They are the tagged NaNs. Do you know of a possible usage of them? :-)
 


I believe Tango uses them. I haven't looked at their implementation but a
reasonable use would be to give information about why the exception was raised;
e.g. there are a lot of ways an "Invalid Operation" flag can be raised and the
tag can distinguish them. 1 = invalid operand, 2 = trying to add -infinity to
infinity, etc.

The other issue is that it is a valid implementation to leave the fields
unchanged when the number is converted to a NaN, so that they could have any
content at all. (The specification states that the fields are undefined.) This
would defeat a bitwise comparison.

 
 And, according to the General Decimal Arithmetic Specification
(http://speleotrove.com/decimal) comparing NaN with any number, including
another NaN, will never return true.<


 (Note: I am not proposing of introducing "== nan" in D, that enhancement
request is just about the "is" operator).
 There are situations where you want to know if a number is any NaN (or if it's
specifically the NaN used by D to initialize floats/reals/doubles). The
std.math.isNaN() function is useful.
 
 Bye,
 bearophile


I hear you, but I'm leary of changing the meaning of the "is" keyword for this
one case. The general decimal spec also requires a "compare-total" operation
which always returns (-1, 0, 1) for numbers and Nans.

From the spec:

"The total ordering is defined as follows.
1.The following items describe the ordering for representations whose sign is
0. If the sign is 1, the order is reversed. A representation with a sign of 1
is always lower in the ordering than one with a sign of 0.
2.Numbers (representations which are not NaNs) are ordered such that a larger
numerical value is higher in the ordering. If two representations have the same
numerical value then the exponent is taken into account; larger (more positive)
exponents are higher in the ordering.
3.All quiet NaNs are higher in the total ordering than all signaling NaNs.
4.Quiet NaNs and signaling NaNs are ordered according to their payload; a
larger payload is higher in the ordering."

That seems complete, but it doesn't make sense (to me) to implement it as "is"
(totalCompare (x,y) == 0)

Paul