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

[Wolf McNally <[e-mail]>]

For us, minimizing absolute size of serialization of a numeric value is less of a goal than having a single, deterministic serialization for a given value. In addition, dCBOR codec implementors should be able to forego floating point or bignum support, and still be able to expect the same canonical serialization for all the integers representable by major types 0 and 1.

~ Wolf
Lead Researcher, Blockchain Commons

> On Mar 10, 2023, at 11:06 PM, 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.
> 
> It would (IMO) be unwise trying to fix this in dCBOR.
> 
> Anders
> 
> On 2023-03-10 20:14, Carsten Bormann wrote:
>> Hi Laurence,
>> I think your arguments are important.
>> But for a receiver of information, there are also benefits from knowing what to expect.
>> In particular map processing can be simpler if only a specific sequence of the entries needs to be accepted.
>> Whether floating point values are important for an application may also influence whether it is worth to expend some additional processing.  The simplest devices often get by without any floating point operations.  Once floating point becomes important for the functioning of a device, processors such as those of ARM’s Cortex M4 series can help reduce the power-hungry on-time of the device by efficiently performing the floating point computations.  With these processors (and certainly with processors of the smartphone, laptop, and server classes), the requirements of dCBOR become almost trivial.
>> I don’t want to take a particular side here, just point out that not all applications are the same.  Having a go-to profile of CBOR that covers an interesting subset of applications appears to be a net win to me.
>> Additional CDDL support such as that provided in draft-bormann-cbor-cddl-more-control with .cbordet and .cborseqdet may be desirable.  There is currently no way in CDDL to express the rules about number representation that dCBOR has adopted; that may be one interesting gap.
>> Little aside: When I started to think about this, I started to wonder: What is the dCBOR way to represent 65536000000.0?
>> 5 bytes:
>>>> 65536000000.0.to_cbor.hexs
>> => "fa 51 74 24 00"
>> 9 bytes:
>>>> 65536000000.to_cbor.hexs
>> => "1b 00 00 00 0f 42 40 00 00”
>> Here, the floating point representation is shorter…
>> But wait, even if float32 cannot be exact (e.g., for 65536000001), try:
>> 7 bytes:
>>>> CBOR.decode("c2 45 0f 42 40 00 01".xeh)
>> => 65536000001
>> 9 bytes:
>>>> CBOR.decode("c2 45 0f 42 40 00 01".xeh).to_cbor.hexs
>> => "1b 00 00 00 0f 42 40 00 01”
>> (Number systems are always an unwieldy part of representation formats.)
>> Grüße, Carsten
>> _______________________________________________
>> CBOR mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cbor
>