exact behavior of Float.NaN and Double.NaN

On Mon, Nov 23, 2009 at 3:45 PM, Paul Phillips wrote:
> [Note: this email could really use some input from anyone who
> intentionally uses NaN for its nanny qualities, or who uses Floats and
> Doubles in such a way that NaN's precise behavior is important.]
>
> There is an interesting corner case with NaN and equality.  In java
> primitive NaN != NaN but NaN.equals(NaN) is true.  As far as I have yet
> discovered this is the only case where the boxed type has wider equality
> than the primitive.  Now that those are unified in scala we have a
> pickle because if NaN must never be equal to NaN, we lose a valuable
> optimization (see below) and in addition you can't ever get NaN back out
> of a hashtable, which was apparently part of the motivation for the
> boxed types returning equal in java.
>
> Here is the current (elegantly distilled) inlined equals method:
>
>    if (x eq y) true
>    else if (x eq null) false
>    else if (x.isInstanceOf[java.lang.Number] || x.isInstanceOf[java.lang.Character]) BoxesRunTime.equals2(x, y)
>    else x.equals(y)
>
> (Sidebar: this requires that equals be implemented such that (x eq y) is
> always true and (x eq null) is always false.  It's easy to violate both
> those requirements today by e.g. defining equals to be constant true or
> false.  This way is definitely good news, but if you were doing anything
> weird with equals you might want to take note.)
>
> This logic now presents a small escape hatch on the NaN issue, because
> the boxed types will short circuit true on reference equality if it's
> the same box.  So we would largely recapture the java behavior for NaN
> if the NaN boxes were singletons.  And we could do that at some
> performance cost, at least when it comes to scala produced values.
>
>    public static Float boxToFloat(float f) {
>        // instead of...
>        // return Float.valueOf(f);
>        Float box = Float.valueOf(f);
>        if (box.isNaN()) return FloatNaN;
>        else return box;
>    }
>
> (That's not the only spot which would need changing, but the same idea
> applies elsewhere.) Should we consider something along these lines? I
> honestly have little idea how frequently NaN comes up in real life, but
> I do get the impression it's not a non-issue.
>
> ** And here is there some NaN-using person would clarify how and where
> NaN is used and what impact they anticipate from doing or not doing
> something about the status quo. **
>
> A less ambitious adjustment is to create well defined boxes in the scala
> math package object:
>
>  final val FloatNaN: java.lang.Float = Float.NaN
>  final val DoubleNaN: java.lang.Double = Double.NaN
>
> The problem is that this doesn't solve much, because your primitives
> will not be boxed into these boxes.  Once you're managing the boxing by
> hand you could simply be calling .isNaN() on the operands.
>
> Maybe this is an unimportant fringe issue, which would be great, but as
> long as I have equality this much on the brain I figured I'd better get
> it out of my system.

NaN is more an abomination than a number. As far as I recall, the IEEE
standard intended it as an error value that's sticky in computations.
It certainly was never intended as a real value -- the only thing you
should ever do on a NaN is ask it with isNaN. All that said, I think
it's a non-issue. I would not slow down float boxing or anything else
by one cycle to make NaN more into a regular value than it is now.

Cheers

Despite the usage of NaN in scientifical computing (It's another
story). What I concern is the consistent of equality of Float.NaN vs a
container that contains Float.NaN

scala> var s = Set[Any]()
s: scala.collection.immutable.Set[Any] = Set()

scala> val a = Float.NaN
a: Float = NaN

scala> s += a

scala> s(a)
res26: Boolean = false

scala> val b = Array(Float.NaN)
b: Array[Float] = Array(NaN)

scala> s += b

scala> s(b)
res28: Boolean = true

scala> val c = Some(Float.NaN)
c: Some[Float] = Some(NaN)

scala> s += c

scala> s(c)
res30: Boolean = true

On Mon, Nov 23, 2009 at 11:00 PM, martin odersky wrote:
> On Mon, Nov 23, 2009 at 3:45 PM, Paul Phillips wrote:
>> [Note: this email could really use some input from anyone who
>> intentionally uses NaN for its nanny qualities, or who uses Floats and
>> Doubles in such a way that NaN's precise behavior is important.]
>>
>> There is an interesting corner case with NaN and equality.  In java
>> primitive NaN != NaN but NaN.equals(NaN) is true.  As far as I have yet
>> discovered this is the only case where the boxed type has wider equality
>> than the primitive.  Now that those are unified in scala we have a
>> pickle because if NaN must never be equal to NaN, we lose a valuable
>> optimization (see below) and in addition you can't ever get NaN back out
>> of a hashtable, which was apparently part of the motivation for the
>> boxed types returning equal in java.
>>
>> Here is the current (elegantly distilled) inlined equals method:
>>
>>    if (x eq y) true
>>    else if (x eq null) false
>>    else if (x.isInstanceOf[java.lang.Number] || x.isInstanceOf[java.lang.Character]) BoxesRunTime.equals2(x, y)
>>    else x.equals(y)
>>
>> (Sidebar: this requires that equals be implemented such that (x eq y) is
>> always true and (x eq null) is always false.  It's easy to violate both
>> those requirements today by e.g. defining equals to be constant true or
>> false.  This way is definitely good news, but if you were doing anything
>> weird with equals you might want to take note.)
>>
>> This logic now presents a small escape hatch on the NaN issue, because
>> the boxed types will short circuit true on reference equality if it's
>> the same box.  So we would largely recapture the java behavior for NaN
>> if the NaN boxes were singletons.  And we could do that at some
>> performance cost, at least when it comes to scala produced values.
>>
>>    public static Float boxToFloat(float f) {
>>        // instead of...
>>        // return Float.valueOf(f);
>>        Float box = Float.valueOf(f);
>>        if (box.isNaN()) return FloatNaN;
>>        else return box;
>>    }
>>
>> (That's not the only spot which would need changing, but the same idea
>> applies elsewhere.) Should we consider something along these lines? I
>> honestly have little idea how frequently NaN comes up in real life, but
>> I do get the impression it's not a non-issue.
>>
>> ** And here is there some NaN-using person would clarify how and where
>> NaN is used and what impact they anticipate from doing or not doing
>> something about the status quo. **
>>
>> A less ambitious adjustment is to create well defined boxes in the scala
>> math package object:
>>
>>  final val FloatNaN: java.lang.Float = Float.NaN
>>  final val DoubleNaN: java.lang.Double = Double.NaN
>>
>> The problem is that this doesn't solve much, because your primitives
>> will not be boxed into these boxes.  Once you're managing the boxing by
>> hand you could simply be calling .isNaN() on the operands.
>>
>> Maybe this is an unimportant fringe issue, which would be great, but as
>> long as I have equality this much on the brain I figured I'd better get
>> it out of my system.
>
> NaN is more an abomination than a number. As far as I recall, the IEEE
> standard intended it as an error value that's sticky in computations.
> It certainly was never intended as a real value -- the only thing you
> should ever do on a NaN is ask it with isNaN. All that said, I think
> it's a non-issue. I would not slow down float boxing or anything else
> by one cycle to make NaN more into a regular value than it is now.
>
> Cheers
>
>  -- Martin
>

On Mon, Nov 23, 2009 at 11:37:23PM +0800, Caoyuan wrote:
> scala> var s = Set[Any]()
> s: scala.collection.immutable.Set[Any] = Set()
>
> scala> val a = Float.NaN
> a: Float = NaN
>
> scala> s += a
>
> scala> s(a)
> res26: Boolean = false

This is a consequence of the inlinedEquals logic not being used
everywhere yet. If you were to build trunk optimised (so inlinedEquals
was always used) it would be true.

On Mon, Nov 23, 2009 at 4:37 PM, Caoyuan wrote:
> Despite the usage of NaN in scientifical computing (It's another
> story). What I concern is the consistent of equality of Float.NaN vs a
> container that contains Float.NaN
>
NaN is not a value. You really should not store it in a container. If
you do, all bets are off. We will not slow down everybody's equality
or other operations to bring sanity for NaN, because I believe that no
such sanity is possible anyway,

Cheers

On Mon, 2009-11-23 at 16:00 +0100, martin odersky wrote:
> the only thing you should ever do on a NaN is ask it with isNaN.

That's how I feel too.

Best,
Ismael

So, the two exceptions in Java's Float object to allow hash tables to
operate properly will not be kept in Scala:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Float.html#equals(java.lang.Object)
=============
However, there are two exceptions:

If f1 and f2 both represent Float.NaN, then the equals method returns
true, even though Float.NaN==Float.NaN has the value false.
If f1 represents +0.0f while f2 represents -0.0f, or vice versa, the
equal test has the value false, even though 0.0f==-0.0f has the value
true.
=============

That's Ok, but we may need to document it.

Cheers,
-Caoyuan

On Tue, Nov 24, 2009 at 12:01 AM, Ismael Juma wrote:
> On Mon, 2009-11-23 at 16:00 +0100, martin odersky wrote:
>> the only thing you should ever do on a NaN is ask it with isNaN.
>
> That's how I feel too.
>
> Best,
> Ismael
>
>

On Mon, Nov 23, 2009 at 8:01 AM, Ismael Juma wrote:
> On Mon, 2009-11-23 at 16:00 +0100, martin odersky wrote:
>> the only thing you should ever do on a NaN is ask it with isNaN.
>
> That's how I feel too.

As someone who mostly writes numerical code involving logs (and
therefore getting the occasional NaN by mistake), the only use I've
ever had for NaN is to check if it's NaN and then crash the program.

Frankly, if you made equals throw an error on NaN, I'd be even
happier. But I know that's not going to happen.

On Mon, 2009-11-23 at 09:50 -0800, David Hall wrote:
> As someone who mostly writes numerical code involving logs (and
> therefore getting the occasional NaN by mistake), the only use I've
> ever had for NaN is to check if it's NaN and then crash the program.

Same here.

> Frankly, if you made equals throw an error on NaN, I'd be even
> happier. But I know that's not going to happen.

What I'd really like is a way to throw an exception if the result of
something ended up as NaN. Having to track that down manually can be a
pain. More of a JVM request than Scala down.

Best,
Ismael

On Mon, Nov 23, 2009 at 9:57 AM, Ismael Juma wrote:
> On Mon, 2009-11-23 at 09:50 -0800, David Hall wrote:
>
>> Frankly, if you made equals throw an error on NaN, I'd be even
>> happier. But I know that's not going to happen.
>
> What I'd really like is a way to throw an exception if the result of
> something ended up as NaN. Having to track that down manually can be a
> pain. More of a JVM request than Scala down.

Well, yes, that would be ideal. :-) But I know that's absolutely never
going to happen...

I use NaN as invalid value sometimes, since the default initial value
0f is not suitable to indicate that it's invalid. Some people use null
or Float.MAX_VALUE or Float.POSITIVE_INFINITY. null is not suitable
in case of primitive float. Using Float.MAX_VALUE will bring a lot of
if-else code too.

For a simplest example, a requirement could be: if v is invalid, then
sum of v should also be invalid
===============
val vs: Array[Float] = ...

var sum = 0f
for (v <- vs) {
if (v == Float.MAX_VALUE) sum = Float.MAX_VALUE else sum += v
}
================

With NaN, I can just write:
================
var sum = 0f
for (v <- vs) {
sum += v
}
=================

NaN is the only value that any operation upon it will return itself (NaN)

Cheers,
-Caoyuan

On Tue, Nov 24, 2009 at 2:03 AM, David Hall wrote:
> On Mon, Nov 23, 2009 at 9:57 AM, Ismael Juma wrote:
>> On Mon, 2009-11-23 at 09:50 -0800, David Hall wrote:
>>
>>> Frankly, if you made equals throw an error on NaN, I'd be even
>>> happier. But I know that's not going to happen.
>>
>> What I'd really like is a way to throw an exception if the result of
>> something ended up as NaN. Having to track that down manually can be a
>> pain. More of a JVM request than Scala down.
>
> Well, yes, that would be ideal. :-) But I know that's absolutely never
> going to happen...
>

On Mon, Nov 23, 2009 at 5:14 PM, Caoyuan wrote:
> So, the two exceptions in Java's Float object to allow hash tables to
> operate properly will not be kept in Scala:
>
> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Float.html#equals(java.lang.Object)
> =============
> However, there are two exceptions:
>
> If f1 and f2 both represent Float.NaN, then the equals method returns
> true, even though Float.NaN==Float.NaN has the value false.
> If f1 represents +0.0f while f2 represents -0.0f, or vice versa, the
> equal test has the value false, even though 0.0f==-0.0f has the value
> true.
> =============
>
> That's Ok, but we may need to document it.
>
We need to document equality in any case in the spec, but that's
probably not the right place to discuss differences between Java and
Scala. Maybe we need a separate document for this.

Cheers

On Mon, Nov 23, 2009 at 7:40 AM, martin odersky wrote:
> On Mon, Nov 23, 2009 at 4:37 PM, Caoyuan wrote:
>> Despite the usage of NaN in scientifical computing (It's another
>> story). What I concern is the consistent of equality of Float.NaN vs a
>> container that contains Float.NaN
>>
> NaN is not a value. You really should not store it in a container. If
> you do, all bets are off. We will not slow down everybody's equality
> or other operations to bring sanity for NaN, because I believe that no
> such sanity is possible anyway,

Regardless, anyone who is testing floats for equality is asking for
trouble anyway. Even more so if they're using hashcodes...

A different topic, but somewhat related:

What's the deal with Float/Double literals for negative zero? Josh Cough just brought to my attention a puzzler that boils down to:

  def equal(x: java.lang.Double, y: java.lang.Double) = x.equals(y) // defined in Java, hence .equals

  val zero = 0.0
  equal(-0.0, -0.0) // true
  equal(-zero, -zero) // true
  -0.0 == -zero // true
  -zero == -0.0 // true
  equal(-0.0, -zero) // false!
  equal(-zero, -0.0) // false!

In the equivalent Java, these are all true.

It turns out that the -0.0 and -0.0f literals are actually turned into positive zero by Scala. However, -zero is a true negative zero. In Java, even though 0.0 == -0.0 is true, zero.equals(-zero) is false. So in Scala, when the -0.0 literal is turned into positive zero, our "equal" method seems to break.

--j

On Mon, Nov 23, 2009 at 6:45 AM, Paul Phillips <paulp@improving.org> wrote:

[Note: this email could really use some input from anyone who
intentionally uses NaN for its nanny qualities, or who uses Floats and
Doubles in such a way that NaN's precise behavior is important.]

There is an interesting corner case with NaN and equality.  In java
primitive NaN != NaN but NaN.equals(NaN) is true.  As far as I have yet
discovered this is the only case where the boxed type has wider equality
than the primitive.  Now that those are unified in scala we have a
pickle because if NaN must never be equal to NaN, we lose a valuable
optimization (see below) and in addition you can't ever get NaN back out
of a hashtable, which was apparently part of the motivation for the
boxed types returning equal in java.

Here is the current (elegantly distilled) inlined equals method:

   if (x eq y) true
   else if (x eq null) false
   else if (x.isInstanceOf[java.lang.Number] || x.isInstanceOf[java.lang.Character]) BoxesRunTime.equals2(x, y)
   else x.equals(y)

(Sidebar: this requires that equals be implemented such that (x eq y) is
always true and (x eq null) is always false.  It's easy to violate both
those requirements today by e.g. defining equals to be constant true or
false.  This way is definitely good news, but if you were doing anything
weird with equals you might want to take note.)

This logic now presents a small escape hatch on the NaN issue, because
the boxed types will short circuit true on reference equality if it's
the same box.  So we would largely recapture the java behavior for NaN
if the NaN boxes were singletons.  And we could do that at some
performance cost, at least when it comes to scala produced values.

   public static Float boxToFloat(float f) {
       // instead of...
       // return Float.valueOf(f);
       Float box = Float.valueOf(f);
       if (box.isNaN()) return FloatNaN;
       else return box;
   }

(That's not the only spot which would need changing, but the same idea
applies elsewhere.) Should we consider something along these lines? I
honestly have little idea how frequently NaN comes up in real life, but
I do get the impression it's not a non-issue.

** And here is there some NaN-using person would clarify how and where
NaN is used and what impact they anticipate from doing or not doing
something about the status quo. **

A less ambitious adjustment is to create well defined boxes in the scala
math package object:

 final val FloatNaN: java.lang.Float = Float.NaN
 final val DoubleNaN: java.lang.Double = Double.NaN

The problem is that this doesn't solve much, because your primitives
will not be boxed into these boxes.  Once you're managing the boxing by
hand you could simply be calling .isNaN() on the operands.

Maybe this is an unimportant fringe issue, which would be great, but as
long as I have equality this much on the brain I figured I'd better get
it out of my system.

--
Paul Phillips      | Appreciation is a wonderful thing; it makes what is
Analgesic          | excellent in others belong to us as well.
Empiricist         |     -- Voltaire
pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------

On Mon, Nov 23, 2009 at 03:50:04PM -0800, Jorge Ortiz wrote:
> What's the deal with Float/Double literals for negative zero?

I opened it a couple months ago.

https://lampsvn.epfl.ch/trac/scala/ticket/2378
"float parsing and IEEE 754 conformance"

I

On Tue, Nov 24, 2009 at 3:28 AM, Paul Phillips wrote:
> On Mon, Nov 23, 2009 at 03:50:04PM -0800, Jorge Ortiz wrote:
>> What's the deal with Float/Double literals for negative zero?
>
> I opened it a couple months ago.
>
> https://lampsvn.epfl.ch/trac/scala/ticket/2378
> "float parsing and IEEE 754 conformance"
>
I just added the following comment to that ticket:

I think again there's nothing we can do. Here are three facts.

1. In order to make structural types work, Scala's boxed types are the
same as Java's. So scala.Float gets transparently boxed to
java.lang.Float.

2. We have decided against simple overloading for equality, because
the result of equality might then be different under automatic boxing.

3. == on scala.Float should follow the IEEE standard, which means 0f == -0f.

Ergo, for == on java.lang.Float the same definition of equality has to
hold. If you are not happy with that, you need to drop one of the
three assumptions above.

So for me it's a wontfix.

Cheers

On Tue, Nov 24, 2009 at 02:07:19PM +0100, martin odersky wrote:
> 1. In order to make structural types work, Scala's boxed types are the
> same as Java's. So scala.Float gets transparently boxed to
> java.lang.Float.
>
> 2. We have decided against simple overloading for equality, because
> the result of equality might then be different under automatic boxing.
>
> 3. == on scala.Float should follow the IEEE standard, which means 0f == -0f.

When I opened that ticket none of this equality stuff was going on.
What it is reporting is that the parser misparses -0.0f and does not
leave you with a negative zero.

scala> -0.0f
res0: Float = 0.0

I think that should either be a parse error or -0.0f, but I can't see
any legitimate way for it to be +0.0f.

I agree with Paul's reading. Equality need not change in this case, but the parser is acting funny.

--j

On Tue, Nov 24, 2009 at 5:49 AM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Nov 24, 2009 at 02:07:19PM +0100, martin odersky wrote:
> 1. In order to make structural types work, Scala's boxed types are the
> same as Java's. So scala.Float gets transparently boxed to
> java.lang.Float.
>
> 2. We have decided against simple overloading for equality, because
> the result of equality might then be different under automatic boxing.
>
> 3. == on scala.Float should follow the IEEE standard, which means 0f == -0f.

When I opened that ticket none of this equality stuff was going on.
What it is reporting is that the parser misparses -0.0f and does not
leave you with a negative zero.

scala> -0.0f
res0: Float = 0.0

I think that should either be a parse error or -0.0f, but I can't see
any legitimate way for it to be +0.0f.

--
Paul Phillips      | Adultery is the application of democracy to love.
Caged Spirit       |     -- H. L. Mencken
Empiricist         |
pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------

+1, if my vote counts.

On Tue, Nov 24, 2009 at 9:17 AM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

I agree with Paul's reading. Equality need not change in this case, but the parser is acting funny.

--j

On Tue, Nov 24, 2009 at 5:49 AM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Nov 24, 2009 at 02:07:19PM +0100, martin odersky wrote:
> 1. In order to make structural types work, Scala's boxed types are the
> same as Java's. So scala.Float gets transparently boxed to
> java.lang.Float.
>
> 2. We have decided against simple overloading for equality, because
> the result of equality might then be different under automatic boxing.
>
> 3. == on scala.Float should follow the IEEE standard, which means 0f == -0f.

When I opened that ticket none of this equality stuff was going on.
What it is reporting is that the parser misparses -0.0f and does not
leave you with a negative zero.

scala> -0.0f
res0: Float = 0.0

I think that should either be a parse error or -0.0f, but I can't see
any legitimate way for it to be +0.0f.

--
Paul Phillips      | Adultery is the application of democracy to love.
Caged Spirit       |     -- H. L. Mencken
Empiricist         |
pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------