## digitalmars.D - Re: Can we drop casts from float to bool?

- bearophile <bearophileHUGS lycos.com> Mar 24 2010

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

Mar 24 2010

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

Mar 24 2010

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

Mar 24 2010

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

Mar 24 2010