I just debugged a test failure down to different r...
# random
e
I just debugged a test failure down to different results on different JVMs:
Copy code
import kotlin.math.*
sin(85.05112877980658 * PI / 180)
0.9962720762207499
(
Double.fromBits(0x3fefe175fa29280f)
) with Java 11 and Java 17 on Linux x86-64 as well as Java 11 on Apple Silicon •
0.99627207622075
(
Double.fromBits(0x3fefe175fa292810)
) with Java 17 on Apple Silicon
👌 5
👍 2
no, I'm not testing for equality, but I am testing that certain points remain in bounds after https://en.wikipedia.org/wiki/Web_Mercator_projection, and this one bit just happens to cause some other arithmetic to go wrong
anyhow, I ended up rewriting it in a more numerically-stable fashion, but it would have been convenient if there were some way to use
java.lang.StrictMath
instead of
java.lang.Math
from `kotlin.math.*`…
speaking of which. have there been any proposals to allow for hexadecimal floating point literals in Kotlin like in several other languages? it would be clearer to talk about
Copy code
0x1.fe175fa29280fp-1
0x1.fe175fa292810p-1
than the raw IEEE 754 bit representation
p
looks like fractional hex literals were deliberately dropped (a while back) https://youtrack.jetbrains.com/issue/KT-4528/Lexer-tries-to-read-a-fractional-hex-literal