Using the smallest floating point representation

[windelbouwman]

Hi!

Good to see some action in rust cbor space! Thank you for your efforts.

I have a question regarding the attempt to use the smallest possible datatype to represent the floating point value. For integer values, I'm 100% convinced this is a good idea. For floating point values, I have my doubts, let me list my thoughts:

• floating point is always tricky, there is nan, inf, +inf. There exists signalling NaN and quiet NaN. Is this all handled correctly when shrinking to a smaller floating point type?
• Is the automatic shrinking compatible with other languages? Does the shrinking of the floating point value, based upon it's value, play nice with other languages which use cbor? How do other implementations of cbor deserialization react when a field is sometimes encoded as f64 and sometimes as f32?

I tried to reproduce the issue I faced, I'll give it another shot. It's still located here: pyfisch/cbor#169

[npmccallum]

Hi!

Good to see some action in rust cbor space! Thank you for your efforts.

I have a question regarding the attempt to use the smallest possible datatype to represent the floating point value. For integer values, I'm 100% convinced this is a good idea.

Great!

For floating point values, I have my doubts, let me list my thoughts:

* floating point is always tricky, there is nan, inf, +inf. There exists signalling NaN and quiet NaN. Is this all handled correctly when shrinking to a smaller floating point type?

Yes. Expanding is always lossless. Shrinking is lossy. This is why we only ever shrink in the case that re-expanding produces exactly the same larger value. The equality test for this is a bits representation (.to_bits()) rather than a fuzzy floating point equality.

* Is the automatic shrinking compatible with other languages? Does the shrinking of the floating point value, based upon it's value, play nice with other languages which use cbor? How do other implementations of cbor deserialization react when a field is sometimes encoded as f64 and sometimes as f32?

So long as serde appropriately hints at the value that it wants, we handle the conversion internally and serde knows nothing. Notice that CBOR also supports f16 which serde does not. Other languages will have to deal with this as well. But the behavior of floating points is standardized.