Anyone else been caught a couple times by Kotlin's...

# advent-of-code

[Nir]

Anyone else been caught a couple times by Kotlin's 32 bit integer default? smh

[Paul Woitaschek]

I've switched all my solutions to long

[Nir]

I started to do it, but it can get annoying fast. e.g. I wrote my own sumBy which returns long, but it can't do overload resolution properly with the int version

[Nir]

so if I put that in my utils then all my previous solutions which did import utils.* stop compilling 😛

[Paul Woitaschek]

Use sumBy { it.toLong() }

[Nir]

and there's no way around having to either stick L places, or explicitly specify Long

[Nir]

that doesn't work

[Nir]

sumBy in the standard library is only for Int, exactly for this issue (can't do overload resolution properly)

[Paul Woitaschek]

Then it was called sumOf

[Nir]

ah you're right

[Nir]

thanks!

[Paul Woitaschek]

https://github.com/PaulWoitaschek/Advent-of-Code-2021/blob/45dbd812b260722f0247adee966f75e62666e47b/src/main/kotlin/Day10.kt#L8

[ephemient]

you can explicitly use checked math - the functions to do so exist since Java 8, and it's not that hard to write polyfills for other Kotlin platforms:
https://github.com/ephemient/kotlin-numeric/blob/main/src/commonMain/kotlin/math.kt
https://github.com/ephemient/kotlin-numeric/blob/main/src/jvmMain/kotlin/math.kt
https://github.com/ephemient/kotlin-numeric/blob/main/src/nonJvmMain/kotlin/math.kt

[ephemient]

or, you can rewrite bytecode on the fly to turn them into checked operations, e.g.
https://github.com/ephemient/kotlin-numeric/blob/main/agent/src/main/kotlin/NumericTransformer.kt
https://github.com/ephemient/kotlin-numeric/blob/main/agent-test/src/test/kotlin/AgentTest.kt

[ephemient]

note that if you try to enable checked math on stdlib you're gonna have a bad time, plenty of code makes use of wrapping overflow

[Nir]

yeah, there are workarounds, and we have had this entire discussion before at the last advent of code 🙂 It's just a real shame to default to 32 bit integers when the "penalty" for using 64 bit integers on native is non-existent on most platforms.

[Nir]

though I understand there are valid JVM reasons for it, it's the practical choice, blah blah etc

[Paul Woitaschek]

I just wished I could set some compiler flag to make that the default

[Paul Woitaschek]

I don't think I ever had a case in my career where an overflow wasn't a bug

[Paul Woitaschek]

Same with divison by zero, I always want that one to throw

[Nir]

division by zero does throw, right?

[Paul Woitaschek]

Only for ints

[Paul Woitaschek]

1.0 / 0.0 is infinity

[Nir]

that's pretty ew

[Nir]

you're sure it's not NaN at least?

[Paul Woitaschek]

Yep

[Paul Woitaschek]

https://pl.kotl.in/Sdjl20FYP

[Paul Woitaschek]

That sharing is broken

[Nir]

It's like that in C++ too, I forgot

[Nir]

I guess the justification is that 0 in floating point is "signed"

[Nir]

maybe there is some good practical reason beyond that, but in many/most cases the "sign" of 0 is arbitrary. I can't see a good argument why IEEE preferred 1.0 / (1.0-1.0) to be Inf, rather than NaN, but such is life I guess (and this is not specific to Kotlin of course)

[ephemient]

at least 0.0 / 0.0 is NaN

[ephemient]

although NaN is a whole another ballpark of fun issues…

[ephemient]

oh right though. you can't assume integer divide by 0 always throws on all targets: it doesn't on Kotlin/JS because that's how the underlying platform works

[ephemient]

https://youtrack.jetbrains.com/issue/KT-45073 may be an interesting idea

[ephemient]

e.g. https://github.com/ephemient/kotlin-numeric/commit/7132250efdc79cb7257e3eecb716b209dedf80ad