Inconsistent hash code with Float vs everyone else

[scabug]

scala> (1L << 31) == (1L << 31).toFloat
res0: Boolean = true

scala> (1L << 31).toDouble == (1L << 31).toFloat.toDouble
res1: Boolean = true

scala> (1L << 31).## == (1L << 31).toFloat.##
res2: Boolean = false

Very specific; everything's okay for 30, 32, 33, etc.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-8150?orig=1
Reporter: @Ichoran
Affected Versions: 2.10.3, 2.11.0-M7

[SethTisue]

@Ichoran should this stay open?

[NthPortal]

It's even worse in jshell/Java 9, so if it is a bug, it's in Java too

jshell> 1L << 31
$1 ==> 2147483648

jshell> Long.hashCode($1)
$2 ==> -2147483648

jshell> Float.hashCode((float) $1)
$3 ==> 1325400064

jshell> Double.hashCode((double) $1)
$4 ==> 1105199104

jshell> $1 == (double) $1
$5 ==> true

jshell> $1 == (float) $1
$6 ==> true

Edit: I've also confirmed that boxing does not affect the hashCodes

[eed3si9n]

This is just how java.lang.Float.floatToIntBits is implemented:

Bit 31 (the bit that is selected by the mask 0x80000000) represents the sign of the floating-point number.

I vote to close this issue as works-as-designed.

[NthPortal]

This feels like another argument to get rid of cooperative equality

[sjrd]

@eed3si9n No, this is a bug in scala.runtime.Statics.floatHash. It should ensure that xFloat.## (which desugars into floatHash(xFloat)) be equal to xLong.## when xFloat == xLong.

The problem is that (1L << 31) is a bit peculiar. Its mathematical value is 2^31, which is not a valid Int. When we do iv = fv.toInt, because fv > Int.MaxValue, toInt caps the result to Int.MaxValue, hence iv == Int.MaxValue. Then, the test iv == fv is compiled as iv.toFloat == fv (because of how binary operators between different numeric types work in Java/Scala). But because Int.MaxValue is not representable as is in a Float, it is rounded back to 2^31, i.e., fv. The test therefore returns true, which causes to return iv (Int.MaxValue) as the hash code.

However, that is not consistent with (1L << 31).##, because that value is not considered == to Int.MaxValue.

I think we can fix this issue by explicitly converting fv and iv to Longs before comparing them.

[Ichoran]

Agreed. The ticket should stay open and the bug should be fixed. It says I reported it, but I have no memory of it. Maybe I stored it in memory with the key (1L << 31).toFloat.

[eed3si9n]

ok. That makes sense. I take back my vote.