identical(double.NAN, double.NAN) should be ?

[DartBot]

This issue was originally filed by [email protected]

---

~/projects/dart % cat nan_eq.dart
main() {
  var nan = double.NAN;
  print("$nan == $nan: ${nan == nan}");
  print("$nan === $nan: ${nan === nan}");
}

~/projects/dart % dart nan_eq.dart
NaN == NaN: false
NaN === NaN: true

~/projects/dart % dart/frog/frogsh nan_eq.dart
NaN == NaN: false
NaN === NaN: false

Equality works as expected (like C and JS) and is consistent between the vm and frog/dartc.

Identity is inconsistent between the vm and frog/dartc.

[floitschG]

There is probably a similar case for -0.0 and 0.0.
That is, on the VM I expect -0.0 !== 0.0, and on frog it is probably -0.0 === 0.0.

[DartBot]

This comment was originally written by [email protected]

---

Correct, and in addition to that and perhaps a bit more surprising the VM considers -0.0 !== -0.0 (frog doesn't). Seems like another bug, though.

[DartBot]

This comment was originally written by [email protected]

---

Added Area-Compiler, Triaged labels.

[DartBot]

This comment was originally written by [email protected]

---

Probably will be an issue for dart2js so I moved it there.

---

Removed Area-Compiler label.
Added Area-Dart2JS label.

[kasperl]

Changed the title to: "NaN === NaN identity test differs between the vm and dart2js".

[DartBot]

This comment was originally written by [email protected]

---

This code fails on dart2js:

Expect.identical(double.NAN, double.NAN);

[rakudrama]

Having the language be sensitive to the boxed state of floating point numbers is asking for trouble.

It is not possible to make double.NAN === double.NAN when compiled to JavaScript (without explicitly boxing almost every number) because JavaScript hides the identity of numbers and strings.

On the VM if we demand that double.NAN === double.NAN, then we cannot do many numeric optimizations because the 'box' of the object is observable and should the preserved by optimizations.

   var x = 1.0;
   var y1 = x + 2.3;
   var y2 = x + 2.3;
   ...
   print(y1 === y2);

If double is defined by the library and not by the language, the VM is obliged to box y1 and y2 separately since the optimizer should not change the observable behaviour of the program.

The same set of issues apply to small integers (different implementations may canonicalize small integers with different numbers of bits) and, thanks to JavaScript, strings.

JavaScript made a good call here for the programmer - it is not possible to tell if a number or string is boxed or not and programs are more consistent, more reliable and have more opportunities for optimization because of it. The cost is that === is nearly as expensive as == in common cases.

I believe we are going to try to sidestep this issue by encouraging the use of == by removing === and providing a function identical(x,y) in its place. I have not seen the full rationale which I would expect explains the compromises. I think the spec needs some language to do one of the following:
  1. explain when the optimizer can change the result of identical(x, y).
  2. or say that identical(x, y) is more than bitwise pointer equality to ensure identical() and other identity sensitive operations cannot tell the difference between different objects of certain types.

---

cc @gbracha.

[kasperl]

cc @floitschG.
Set owner to @kasperl.
Added this to the M1 milestone.

[lrhn]

While I would like identical on numbers (and strings) to be bitwise equality, not reference equality, it isn't. Dart2js is still wrong here - identical-tests on the same reference must give true, and the reference in the "nan" variable doesn't change.

[kasperl]

Removed this from the M1 milestone.
Added this to the M2 milestone.

[kasperl]

Removed this from the M2 milestone.

[kasperl]

Added this to the Later milestone.

[kasperl]

Added TriageForM5 label.

[kasperl]

The specification has been updated to treat identical between doubles like this:

The identical() function is the predefined dart function that returns true iff its two arguments are either:
 - The same object.
 - Of type int and have the same numeric value.
 - Of type double, are not NaNs, and have the same numeric value.

As far as I can tell, this works as expected in dart2js, but the VM yields true for the following identical invocation:

   identical(double.NAN, double.NAN)

and should not.

---

Removed the owner.
Removed this from the Later milestone.
Removed Area-Dart2JS, TriageForM5 labels.
Added Area-VM label.
Changed the title to: "vm: identical(double.NAN, double.NAN) should be false".

[kasperl]

The spec is a little bit unclear on how to deal with identical(double.NAN, double.NAN). Doubles are objects so the first clause in the description of identical means that it should return true and the last one means that it should return false. I think it might be worth calling out what we expect identical(NAN, NAN) to be -- and ideally we'll define it so it doesn't depend on boxing only on the numeric value.

---

cc @sgmitrovic.
Removed Area-VM label.
Added Area-Language label.
Changed the title to: "identical(double.NAN, double.NAN) should be ?".

[floitschG]

There is also slight ambiguity what "same numeric value" means.
Does -0.0 have the same numeric value as 0.0? They are ==.

Fwiw I think that two doubles should be identical if they have the same bit-pattern. This assumes that NaN always has the same bit-pattern (and the same sign).
Afaics this is how the VM has identity currently implemented.

[gbracha]

Re comment 15:

The spec (as listed in comment 14) says "either". That means a disjunction among the 3 clauses. So, if you have a NaN boxed in a given object, it is identical to itself. I think it will be costly to do otherwise, but you can decide that with the VM folks as you wish. All I am saying is that there is no ambiguity between the different clauses.

Re comment 16. I agree we need to clarify the treatment of things like -0.0. My reading would be that -0.0 has the same numeric value as 0.0, assuming numeric values come from the real numbers. But maybe you do want to tell them apart somehow.

---

Set owner to @gbracha.
Added Accepted label.

[floitschG]

wrt NaN: I don't think we should ever expose that doubles can be boxed. Therefore making boxed NaNs use the identity on their boxes seems wrong. (Nothing prevents NaNs to be in different boxes). But I think I agree with the intention: identical(NaN, NaN) -> true.

wrt -0.0, 0.0:
I would be surprised if identical(a, b), but a.toString() != b.toString()
Since -0.0 and 0.0 print differently I think they should not be identical.

Maybe it would be easier to spec by saying that the library canonicalizes all numbers (ints and doubles). This makes identical non-special and shifts the burden to the library (at least conceptually).

[gbracha]

Section 12.0.1 of the 0.51 spec deals with this.

---

Added Done label.