https://kotlinlang.org logo
#codereview
Title
# codereview
a

Alanna

04/28/2020, 9:21 PM
I'm calling assertEquals on two lists in a test case, but unfortunately i've run into the issue that list equality calls
.equals()
instead of
==
, the two of which give me a different results.
Copy code
>>> 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
==
?
m

Mike

04/28/2020, 9:38 PM
Use an assertions library that does it for you? AssertJ, hamkrest are examples. Or switch to kotest which is a solid testing framework with great matches and other features?
a

Alanna

04/28/2020, 9:40 PM
I'm using kotest - though it looks like I'm some versions behind. I'll see if upgrading fixes it!
s

Shawn

04/28/2020, 9:51 PM
as far as why this doesn’t work as you expect it to, I think it’s because of how
operator 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)
👍 1
list implementations on the JVM just use
.equals()
afaict and can’t make use of Kotlin’s funky double/float
==
s

sam

04/29/2020, 1:35 AM
If you're using kotest, then try
shouldBe
.
assertEquals
is not part of kotest.
👍 1
a

Alanna

04/29/2020, 4:30 PM
I did the upgrade, but shouldBe is not doing it for me (it's still reporting that listOf(-0f) != listOf(0f). I checked for other matchers but I'm not seeing any would fix this. It seems like from @Shawn’s explanation that there may not actually be a nicer way to do this than writing a custom function to handle my
List<Float>
case?
k

kevin.cianfarini

05/01/2020, 6:41 PM
0f == -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.
The question here should actually be "why is the Float objects equals 0f != -0f" which may actually be an edge case bug that was missed.
s

Shawn

05/01/2020, 7:17 PM
but there are no “primitives” in kotlin — there are some edge cases and known optimizations to primitive types (specific to target platforms), but to the language itself there isn’t a lower-case f
float
k

kevin.cianfarini

05/01/2020, 7:18 PM
We don't see them because they're hidden away from us. There are primitive types in Kotlin.
s

Shawn

05/01/2020, 7:18 PM
plus, you can get boxed floats out of a list, compare them, and see the intended behavior
k

kevin.cianfarini

05/01/2020, 7:23 PM
Any time a generic is involved autoboxing on a float/Float will happen. Lists use generics. I imagine pulling them out of the list and assigning them to a float circumvents that and get you the true primitive type versus the boxed type.
this is true for all primitive types and their object counterparts
As 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.
if he wanted to get around this in his tests, he could use
toTypedArray
which (I believe) should unbox those values into an array of primitives
but there are no “primitives” in kotlin
there's literally a file in Kotlin called Primitives.kt. Directly from the doc comments from
Float
Copy code
/**
 * 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`.
 */
s

Shawn

05/01/2020, 7:34 PM
You have literally pointed out a platform-specific optimization that doesn’t (or at very least shouldn’t) have bearing on the guarantees the language makes with regard to the semantics of float/double comparison
moreover,
floatArrayOf(0.0F, -0.0F).contentEquals(floatArrayOf(0.0F, 0.0F))
still returns
false
k

kevin.cianfarini

05/01/2020, 7:43 PM
from the docs from contentEquals
The elements are compared for equality with the equals function. For floating point numbers it means that
NaN
is equal to itself and
-0.0
is not equal to
0.0
s

Shawn

05/01/2020, 7:44 PM
precisely
if these floats were being unboxed and treated as primitives as a rule, there would be no
.equals()
function to speak of
but all of this is missing the point — the reason
0.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 numbers
special semantics that the collection types and arrays don’t make use of
k

kevin.cianfarini

05/01/2020, 7:51 PM
Yes it seem I was wrong about typed array equality. However, Kotlin (JVM at least) certainly has primitives and the equals semantics of those differ from the object equals semantics, like stated above. Autoboxing would be performed if the elements were grabbed out of the array and compared.
Copy code
floatArrayOf(0f).first() == floatArrayOf(-0f).first() // true
precisely
The docs of
Float
don't mention this equals peculiarity anywhere aside from
contentEquals
on floatArray that I can find.
2 Views