Nicole
06/27/2019, 5:03 PMFloat.NaN
which led to this odd result: Float.NaN === Float.NaN
is false
with JVM and JS targets, and true
with Kotlin/Native. — I see that identity equality for Float
has been deprecated, but still figured I should check if this is a bug (and should be reported) or if it’s just “undefined behavior”karelpeeters
06/27/2019, 5:08 PMNicole
06/27/2019, 5:11 PMkarelpeeters
06/27/2019, 5:14 PM===
, which indeed doesn't really make sense for primitives in the first place.Nicole
06/27/2019, 6:03 PM===
operator returns falsekarelpeeters
06/27/2019, 6:05 PMfalse
since Nan != Nan
according to IEEE.Nicole
06/27/2019, 6:08 PM(Float.valueOf(10) != Float.valueOf(10))
Float.NaN === Float.NaN
in native =/karelpeeters
06/27/2019, 6:10 PMjava.lang.Float.equals
checks for actual bit equality, not IEEE equality. (which it has to because of reflexivity)Float.valueOf(10) == Float.valueOf(10)
on the JVM.Nicole
06/27/2019, 6:12 PM(Float.valueOf(10) != Float.valueOf(10))
on a JVM, and it prints trueSystem.out.println("Floats: " + (Float.valueOf(10) != Float.valueOf(10)));
Output:
Floats: true
damian
06/27/2019, 6:13 PM!=
is comparing reference equality of boxes, so that makes perfect sensekarelpeeters
06/27/2019, 6:14 PM==
so Kotlins ===
, I was talking about Koltin's ==
. You should have said Float.valueOf(10) !== Float.valueOf(10)
😛Nicole
06/27/2019, 6:16 PMFloat.NaN === Float.NaN
is false on a JVM target, but true in a native context.FloatCompanionObject.INSTANCE.getNaN()
referenceskarelpeeters
06/27/2019, 7:30 PM===
does? It's deprecated because it was useless and confusing.