Re: [Cbor] Decoding numbers and compliance verification in dCBOR

[Carsten Bormann <[e-mail]>]

On 11. Mar 2023, at 08:06, Anders Rundgren <[e-mail]> wrote:
> 
> If shortest possible number representation is an absolute goal, you already have a problem with "pure" integers.  An integer value of 1099511627775 (0xffffffffff) would actually yield two bytes less(!) using the Bignums type.

Yes.  This observation was my second example.
It has been somewhat surprising to me how many applications actually need 40-bit numbers a lot...

> It would (IMO) be unwise trying to fix this in dCBOR.

I was not making a recommendation to do this; I’m just pointing out that for 2**32 to 2**48-1 (and the negative) a tag 2/3 representation is more compact than the CBOR major type 0/1 representation, which is an artifact of the large gap between 4- and 8-byte integers, and the byte-wise granularity of byte strings.  Another profile (e.g., one that needs those 40-bit numbers) might choose to do this, maybe not dCBOR.

Back to floating point numbers: For many applications, the ability to represent 1.0 in one byte (instead of three), 4711.0 in three bytes (instead of five) etc. could be of more interest than the above.  Also, if -0.0 scares you, replacing 0.0 and -0.0 with 0 may comfort you.  So I have some sympathy for the dCBOR choices.  But Zipf’s law tells us these applications are rare in the sensor/actuator space, which is why we didn’t suggest that any more in RFC 8949.

One area where the application (possibly in a data model) needs to decide is whether float64 is actually needed or the non-existent precision can be lopped off to float32 (or float16!).  This comes up in sensors that have decimal fractional base, e.g., reading 1.1 V — do you really need "fb 3f f1 99 99 99 99 99 9a” to represent this, or is "fa 3f 8c cc cd” fine, or maybe "f9 3c 66”?  Only the application can know.  Often the same application needs float64 as well (e.g., for some timestamping), and float32 for sensors with a higher resolution, so it can’t be a global setting.

Grüße, Carsten