Alanna
04/28/2020, 9:21 PM.equals()
instead of ==
, the two of which give me a different results.
>>> 0f == -0f
res0: kotlin.Boolean = true
>>> 0f.equals(-0f)
res0: kotlin.Boolean = false
>>> listOf(0f) == listOf(-0f)
res1: kotlin.Boolean = false
The best way I've come up with to solve this is by defining my own assertEquals function that works on List<Float>, but this doesn't seem very clean to me. Is there a better way to do this? Also, why doesn't list equality use ==
?Mike
04/28/2020, 9:38 PMAlanna
04/28/2020, 9:40 PMShawn
04/28/2020, 9:51 PMoperator fun equals()
works — if I understand correctly, there’s no way to override and provide custom operator equals functionality overloaded on a generic type (as List
is usually implemented, anyhow)Shawn
04/28/2020, 9:52 PM.equals()
afaict and can’t make use of Kotlin’s funky double/float ==
sam
04/29/2020, 1:35 AMshouldBe
. assertEquals
is not part of kotest.Alanna
04/29/2020, 4:30 PMList<Float>
case?kevin.cianfarini
05/01/2020, 6:41 PM0f == -0f
compares two primitive types. Lists cannot store primitive types. The floats in the lists are objects. Their equals semantics will be different.
Kotlin does autoboxing of primitive/object types for us automatically.kevin.cianfarini
05/01/2020, 6:42 PMShawn
05/01/2020, 7:17 PMfloat
kevin.cianfarini
05/01/2020, 7:18 PMShawn
05/01/2020, 7:18 PMkevin.cianfarini
05/01/2020, 7:23 PMkevin.cianfarini
05/01/2020, 7:23 PMkevin.cianfarini
05/01/2020, 7:23 PMkevin.cianfarini
05/01/2020, 7:24 PMAs you probably know, the heap allocations are due to boxing and unboxing, which is due to generics.
Getting rid of the boxing/generics in the code you provided requires both inlining and defining specialised (non-generic) versions of the functions.
kevin.cianfarini
05/01/2020, 7:24 PMtoTypedArray
which (I believe) should unbox those values into an array of primitiveskevin.cianfarini
05/01/2020, 7:26 PMbut there are no “primitives” in kotlinthere's literally a file in Kotlin called Primitives.kt. Directly from the doc comments from
Float
/**
* Represents a single-precision 32-bit IEEE 754 floating point number.
* On the JVM, non-nullable values of this type are represented as values of the primitive type `float`.
*/
Shawn
05/01/2020, 7:34 PMShawn
05/01/2020, 7:35 PMfloatArrayOf(0.0F, -0.0F).contentEquals(floatArrayOf(0.0F, 0.0F))
still returns false
kevin.cianfarini
05/01/2020, 7:43 PMThe elements are compared for equality with the equals function. For floating point numbers it means thatis equal to itself andNaN
is not equal to-0.0
0.0
Shawn
05/01/2020, 7:44 PMShawn
05/01/2020, 7:45 PM.equals()
function to speak ofShawn
05/01/2020, 7:50 PM0.0F == -0.0F
has nothing to do with whether or not the compiler is aware of platform-specific primitive types, it’s because ==
has special semantics when comparing floating-point numbersShawn
05/01/2020, 7:51 PMkevin.cianfarini
05/01/2020, 7:51 PMfloatArrayOf(0f).first() == floatArrayOf(-0f).first() // true
kevin.cianfarini
05/01/2020, 7:51 PMkevin.cianfarini
05/01/2020, 7:51 PMFloat
don't mention this equals peculiarity anywhere aside from contentEquals
on floatArray that I can find.