I filed a <bug>, but just wanted to check if this ...
# webassembly
b
I filed a bug, but just wanted to check if this is expected or covered in docs anywhere. I am seeing floating point division behave differently in WASM than in the JVM. is this expected?
Copy code
println(11f / 10f) // executed in wasm outputs 1.100000023841858
println(11f / 10f) // executed in jvm outputs 1.1
p
To me makes perfect sense
b
why would you expect a different result in WASM than jvm?
p
The printer underneath I believe uses platform specific APIs
The binary representation is probably the same but the printer interpret different.
b
interesting theory
If I just render text like
Copy code
Text("Compose: ${11f / 10f}")
I still see different behavior on compose wasm vs compose android
p
Then is not the printer is the double and float operations Float and Double operations will depend on platform APIs. In general KMP just reuse native APIs and it is subjective to this behavior. KMP basically transpile to the platform but the runtime and compiler is from each platform.
👌 1
m
Even if platform APIs are involved they all have to adhere to IEEE 754. You could find out whether it’s the floating point operation or the printing by storing the result of the operation in an intermediate variable and print out its exact 4 byte hex representation. I haven’t tried it but I also think the problem is in the text conversion and not the arithmetic. JavaScript only knows a number type which is always a Double value internally and so all text conversion code will probably expect such a double argument but the result of the division is just a Float. This is just a wild guess now but I assume that JS would first convert both arguments of the division to its number type (Double) and then do the division. So the result is an exact (within its bounds) Double too. Wasm, on the other hand, will probably do the division directly with the two Float arguments. The result will then also be a Float value which has to be extended to a Double afterwards (which is not exact) for the text conversion.
☝🏻 1
👀 1
💯 1
thank you color 1
b
I think it’s fixed in upcoming 2.2.0
👌 1