Idea suggests to simplify `0f == (-0f)` as `false`, which is wrong

# intellij

[elect]

Idea suggests to simplify 0f == (-0f) as false, which is wrong

[Dias]

Although negative zero and positive zero are generally considered equal for comparison purposes, some programming language relational operators and similar constructs treat them as distinct. According to the Java Language Specification,[5] comparison and equality operators treat them as equal, but Math.min() and Math.max() distinguish them (officially starting with Java version 1.1 but actually with 1.1.1), as do the comparison methods equals(), compareTo() and even compare() of classes Float and Double

[karelpeeters]

Doesn't matter, the IDE shouldn't suggest replacing any expression that returns true with false.

[Dias]

oh that's interesting, because I assumed it returns false, given Java spec, and OPs confusion was for different reasons

[karelpeeters]

Well your quote says:

According to the Java Language Specification,[5] comparison and equality operators treat them as equal

[Dias]

but Math.min() and Math.max() distinguish them (officially starting with Java version 1.1 but actually with 1.1.1), as do the comparison methods equals(), compareTo() and even compare() of classes Float and Double

[Dias]

maybe I am reading it wrong

[karelpeeters]

They are equal according to == , but not according to Float.equals.

[karelpeeters]

From the java.lang.Float.equals docs:

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.

[Dias]

I thought == is operator for equals()

[karelpeeters]

Not really it turns out:

val posPrimitive: Float = 0.0f
val negPrimitive: Float = -0.0f

val posBoxed: Float? = posPrimitive
val negBoxed: Float? = negPrimitive

println(posPrimitive == negPrimitive)   //true
println(posBoxed == negBoxed)           //true
println(posBoxed?.equals(negBoxed))     //false

[karelpeeters]

Now I'm confused myself, I would have expected true, false, true.

[Dias]

println(posPrimitive.equals(negPrimitive))   //false

[karelpeeters]

That boxes the primitives and calls the actual Float.equals function, so according to the docs that makes sense.

[elect]

So, I managed to get Karel confused.. excellent ^^

[karelpeeters]

Turns out there literally is a special case for floats in the compiler: https://kotlinlang.org/docs/reference/equality.html#floating-point-numbers-equality

[karelpeeters]

Why is this not a Kotlin puzzler yet?