Re: [Cbor] Bignums and the generic data models (Re: 🔔 WGLC on draft-ietf-cbor-7049bis-09)

[Carsten Bormann <[e-mail]>]

Hi Laurence,

The juicy bit was your last paragraph:

> I don’t think anyone is going to send smaller integer values as the bignum type (some integer values like 0xffffff encode smaller as a bignum type than they would as type 0 and 1, but I don’t think we want to encourage that). 

Exactly.  By making the basic integer the preferred serialization, we make sure that bignums only occur where they are actually needed.  That is a strong reason to keep bignums in the same space as basic integers and to make basic integers, when they fit, the preferred serialization for a single integer domain.

On 2020-01-15, at 22:00, Laurence Lundblade <[e-mail]> wrote:
> 
> I’m in favor of bignums being quite separate:
> - There are very very few use cases for them, many fewer than floating point, as we just don’t need the the range and the precision at the same time

That depends a lot on the application.

If we hadn’t provided bignums as a catch-all, I’m sure we would already have activated ai=30 for 128-bit integers.  With bignums, we probably will never need that (we can still make that step if we really have to).

Bignums are the “design for decades” relief for limiting basic integers to 64 bits.

> - CPUs and programming languages don’t generally or generically support them — if you are writing code for bignums you are writing very specific code

Again, that depends a lot on your application.

> For example, I don’t think it would be useful for a generic decoder to convert bignums less than 0xffffffff to uint32_t and those larger than that to a byte array when returned to the caller.

I would expect the generic decoder to decode a bignum as an integer in the representations provided by the platform (*), just as with basic integers.

Now if the platform doesn’t have such representations, handing up the tag (for plus/minus) and the byte string is exactly what I would recommend a generic decoder to do.

Not being able to decode 2(h’12’) as 18 is somewhat equivalent to not being able to decode 0x1B0000000000000012 as a 32-bit integer on a 32-bit platform — not recommended, but an option that CBOR gives to a generic decoder (both 2(h’12’) and 0x1B0000000000000012 are not in preferred encoding).

> Bignum spelling auto correct: big numb lignum bingo bigness!

My Mac has quickly adapted: bignum (look, ma, no autocorrect!).

Grüße, Carsten

(*) Popular platforms that don’t have arbitrary limits on integer sizes include: Common Lisp, Erlang (of WhatsApp fame), Haskell, Prolog, Python, Racket, Ruby, TCL.
Other platforms such as C#, D, Go, Java, JavaScript, Julia, OCaml provide standard libraries for handling unrestricted integers.  For other languages, there are multiple libraries available to get these, e.g., for C/C++ you can find Boost, GMP, mbedTLS, OpenSSL.