Decoding of 32 bit floats is not precise about msgpack-javascript

[BerndAmend]

I think this library behaves correctly, you see the precision loss of the float64 ⇒ float32 conversion.

> 59.48.toFixed(50)
"59.47999999999999687361196265555918216705322265625000"
> Math.fround(59.48).toFixed(50)
"59.47999954223632812500000000000000000000000000000000"

[ThetaSinner]

I see what you're saying with the conversion but I really need encoding/decoding to round trip correctly so that would suggest to me that the toFixed isn't appropriate. I would prefer to have the exact value unpacked into a JavaScript number, i.e. 64-bit value. The library already encodes that way anyway because it's not working off a schema. At least in that case users of multiple msgpack libraries (in my case, this one and rmp-serde for Rust) would run into clashes between their backend and frontend. So this library encodes as 64-bit, the backend is strictly expecting 32-bit, that will fail, then the user is naturally pushed over to using 64-bit floats in their backend schema. That doesn't restrict users who aren't using a JavaScript frontend and the problem is made much more obvious to those who are

[Aetherus]

This is a typical IEEE 754 rounding error. In short, there's no way to precisely represent the float number 59.48 in 32-bit binary form. The closest floating point number that can be represented is 59.47999954223633.