Someone did several comparisons with `Float.NaN` w...

# announcements

[Nicole]

Someone did several comparisons with Float.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]

It has been deprecated? Where? How?

[Nicole]

It shows up as deprecated in Intellij:

[Nicole]

And this isn’t covered by a test case: https://github.com/JetBrains/kotlin/blob/master/compiler/testData/codegen/box/ieee754/equalsNaN.kt#L154-L226

[karelpeeters]

Ah I didn't see it was ===, which indeed doesn't really make sense for primitives in the first place.

[Nicole]

It seems like (at least for the JVM, and I suspect the same for JS?) is that the values are being boxed, and since there isn’t a cache of boxed values for floating point values the === operator returns false

[Nicole]

In native code, I suspect it just doesn’t (or cannot?) box, so it compares the values and they’re the same.

[karelpeeters]

Err no, them not being boxed would return false since Nan != Nan according to IEEE.

[Nicole]

On the JVM, (Float.valueOf(10) != Float.valueOf(10))

[Nicole]

I figured that explained it, but now I’m just very confused why Float.NaN === Float.NaN in native =/

[karelpeeters]

Wrong again, java.lang.Float.equals checks for actual bit equality, not IEEE equality. (which it has to because of reflexivity)

[karelpeeters]

so Float.valueOf(10) == Float.valueOf(10) on the JVM.

[karelpeeters]

So it's probably the other way around, not boxed on the JVM so unequal but bowed for native so equal.

[Nicole]

I actually ran (Float.valueOf(10) != Float.valueOf(10)) on a JVM, and it prints true

[Nicole]

System.out.println("Floats: " + (Float.valueOf(10) != Float.valueOf(10)));
Output:
Floats: true

[damian]

If this is java, != is comparing reference equality of boxes, so that makes perfect sense

[karelpeeters]

Ah but that's Java's == so Kotlins ===, I was talking about Koltin's ==. You should have said Float.valueOf(10) !== Float.valueOf(10) 😛

[Nicole]

Basically, I’m just trying to understand how Float.NaN === Float.NaN is false on a JVM target, but true in a native context.

[Nicole]

This led me to looking at the JVM bytecode generated (which seemd to be Float.NaN == Float.NaN after resolving the FloatCompanionObject.INSTANCE.getNaN() references

[Nicole]

Just for completeness, I filed a bug about this.

[karelpeeters]

Can I ask why you care about what === does? It's deprecated because it was useless and confusing.