Numeric type classes

I understand that there are generally 2 classes of numbers in CE: integers, and floats. All integers encodings are equivalent. A library may encode integers to whatever size (ideally the smallest) that it chooses. When it decodes an integer, it returns simply "the integer (2)", not "the smallint (2)" or "the uint16 (2)".

Likewise, all floats are considered equivalent, and libraries can treat all of them identical as long as it doesn't lose precision — and so generally decimal floats stay decimal, and binary floats stay binary. Both kinds of floats have inf/nan, and CTE has no way to specify "a binary nan", and that's OK because all floats are the same.

(Is that correct?)

In some cases, though, the reference implementation can silently cross the integer/float boundary:

$ echo 'c1 1.0' | ./enctool convert -df cbe | hexdump -C
00000000  03 00 65 00 01                                    |..e..|
00000005
$ echo 'c1 1.0' | ./enctool convert -df cte
c0
1
$ echo 'c1 1.0' | ./enctool convert -df cte | ./enctool  convert -df cbe | hexdump -C
00000000  03 00 01                                          |...|
00000003

Is this a bug? Should floats always stay floats, and ints always stay ints?

A codec can encode as whatever numeric type it wants so long as it doesn't lose information (other than type information). It would be up to the receiving end to decide how it will store the data.

So if a sender wanted to encode 1.0, it could encode it as float 1.0 or smallint 1 since there's no data loss. The receiving end would receive 1.0 or 1 and store it however it likes (as an int or decimal float or binary float or big int or convert it to string or ...)

The schema (once developed) will allow type restrictions, in which case the decoder must attempt to convert to the expected type. If any data loss occurs, it must raise a decoding error.

Note: String<->numeric conversions will always be forbidden because that's a hornet's nest.