Re: [Cbor] dCBOR moving from numerically-typeless systems

[Carsten Bormann <[e-mail]>]

Hi Wolf,

(This is a nice specimen for what I call the fallacy of hand-crafted examples.)

So it seems your data model is, say:

a = [uint, 1.0..100.0, -14..68, float, float16]

(I’m guessing from your example, using uint and int as well as a floating point range just to point out that there may be other application-level type requirements than int vs. float.)

You already assume that, when extracting these values, you know the data model so you can hand the right type to the application (u64, f64, i8, f64, f16).  So you might as well employ that information for encoding.

You picked the example so that it actually has a benefit for the mixed integer/float encoding.
But where your data model has floating point values, you are likely to have actual values all over the place, and the percentage of integral values (no fractional part) that you can represent as integers is low (depending on range — if you have a value from 1024.0 to 2047.0 with 10-bit precision, you are going to be more lucky of course :-), (but then there is no size difference in that particular range).

If you are stuck with the JavaScript number system, you’ll want to represent the full-range uint in position 0 as a BigInt (see RFC 7493): you can’t just push all numbers into binary64 (float64), losing exactness.

Again, I very much sympathize with the choices dCBOR makes (it was pretty much how I looked at things in 2013), I just wanted to point out where your hand-crafted example is missing out on additional considerations that just don’t pop up in that example, but do in my hand-crafted one :-).

Grüße, Carsten