Data model changed in Draft to separate floating point from integer types

[jimsch]

In the current working group document, the data model distinguishes between a floating point and an integer type. Section 2 - bullets 1 and 3. What are the plans for moving this into the current codebase?

[peteroupc]

Here is the current situation:

• The library does distinguish integers and (IEEE) floating-point numbers internally, but conflates those types to a single Type, CBORType.Number.
• Integers represented by major types 1 and 2 and bignums with tag 2 and 3 are both treated internally as "big integers" when their value is in the range [2^63, 2^64-1] or [-2^64, -2^63-1].
• A CBOR map currently stores CBORObject.FromObject(0) and CBORObject.FromObject(0.0) as distinct items.
• CBORObject's CompareTo method compares objects representing numbers (including integers, "doubles", "singles", decimal fractions, bigfloats, and rational numbers) according to their numerical values. One "kind" of number does not compare higher or lower than another kind in all cases.
• Items with tags 2 and 3 are stored as EInteger.
• Items with major types 0 and 1 are stored either as long or as EInteger depending on their value.
• Items with tag 30 are stored as ERational.
• Items with tag 5 or 265 are stored as EFloat.
• Items with tag 4 or 264 are stored as EDecimal.
• Items representing IEEE 16- or 32-bit floating point numbers are stored as float.
• Items representing IEEE 64-bit floating point numbers are stored as double.

[jimsch]

First, I assume you meant to say tags 0 and 1 not 2 and 3 - Kind of hard to store a text string in an EInteger.

What I am currently playing with is CoRAL (https://datatracker.ietf.org/doc/draft-hartke-t2trg-coral/). There is a optimization with dictionaries that I need to figure out how to program. Looking inside of the object might be one way, but I would worry if you changed it again.

The hack is that you can replace specific elements in an array with an integer that comes from a dictionary so that [1, "ABCDE", "FGHIJ"] can be converted to [1, 10, 11] which is much shorter. The problem is that it is supposed to be possible to replace an integer value as well. Thus [1, "ABCDE", 99999] can be mapped to [1, 10, TBD(12)]. The value is tagged so that one can distinguish between it being an integer and being something else like a string. When doing the reverse mapping that means I need to figure out the difference between a floating point and an integer so that [1, 10, 12.0] is not mapped back. The model assumes that the tag that was decoded is visible to the application but I don't believe that is true for you systems.

[peteroupc]

Yes, when my library encounters CBOR objects with certain tags, it converts that object to a "native" version with a different form of storage and discards the tag; see ConvertToNativeObject in the CBORNativeConvert class of my library. However, it preserves the tag information in the case of all other tags.

I will work at rewriting the code to eliminate this kind of conversion and to preserve the distinction between integers and IEEE floating point numbers in the public API.

[jimsch]

Thanks

[peteroupc]

Issue addressed in version 4.0.0-beta2, just released.