Float reading and writing is inconstent on Kotlin JS about kotlinx-io HOT 4 CLOSED

Float behaving as Double in KotlinJS is discussed here.
https://youtrack.jetbrains.com/issue/KT-24975/Enforce-range-of-Float-type-in-JS

from kotlinx-io.

As writeFloat/readFloat documentation stated, these functions use Float.toBits and Float.fromBits to serialize floats to bitstream and back.
On JS, Floats have a wider range (as they are backed by Number, which is an IEEE 745 double-prevision 64-bit floating point number), so Float.toBits may produce numbers that are not equal to initial values (see docs).

The only thing we can improve here is stressing this peculiarity in docs.

from kotlinx-io.

Thanks for the clarification. As there is also writeDouble/readDouble, this is very unexpected if you don't know that JS is only using 64-bit floating points underneath. I don't know if it is possible to trim the float values to 32-bit precision stored in a 64-bit variable?

from kotlinx-io.

I don't know if it is possible to trim the float values to 32-bit precision stored in a 64-bit variable?

Sure, it's possible, but with potential precision loss (which is always the case for values that could not be represented exactly, like 0.999).

While JS Numbers are always double-precision floating point numbers, JS also provides TypedArrays, where values have fixed width in binary representation. When writing values into these arrays, 64-bit fp Numbers are converted to an arrays' type (in fact, semantics is defined for storing in array's buffer, with the float64 to float32 conversion described here).

To "trim" double-precision fp to a single-precision fp, Kotlin's Float.toBits uses typed arrays with a shared buffer to extract Float's binary representation. As a result, we can get 4 bytes representing a IEEE 754 single-precision fp that was obtained by rounding double-precision Number backing the Float.

Float.fromBits performs transformation in the opposite direction, but reading a value from JS Float32Array converts it back to Number with mantissa least significant bits being "zero-padded", leading to 0.999f not being equal to Float.fromBits(0.999f.toBits()).

from kotlinx-io.