Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Anders Rundgren <[e-mail]>]

On 2022-03-01 23:21, Laurence Lundblade wrote:
> Got it. Made PR to remove half-precision exclusion <https://github.com/ietf-rats-wg/eat/pull/172> from location. Thanks for the discussion and foot notes!
>
> Checked a few decoders and can see that half-precision decoding is often supported.

Encoders can also provide full support (including subnormal values) for half-precision at the expense of 100-150 bytes of code:
https://github.com/cyberphone/D-CBOR/blob/main/lib/d-cbor-ieee754.c

Anders


>
> LL
>
>> On Feb 23, 2022, at 1:08 PM, Carsten Bormann <[e-mail]> wrote:
>>
>>>>
>>>> This discussion was more about lat/lon.
>>>> cti (label 7) is a byte string, so there is no such problem there.
>>>
>>> Lat/long needs double precision float to be useful to beings the size of humans on a planet of earth's size. Half-precision has so little precision on a planet of earth's size that it is useless for location.
>>
>> That is not what this is about.
>>
>> Saying “You need 16 bits to express the unsigned integer weight of a street vehicle in kg” does not mean that I can’t encode the weight of my bike in 8 bits.
>> What the current text in EAT says is equivalent to "you can’t ever use 8 bits because some vehicles need 16".  That is not smart.
>>
>>> I mis-remembered “iat” as “cti”. Iat is a time stamp. A uint64 can represent everything needed for a time stamp, 1 second precision and +/- 500 million years. Float adds no value.
>>
>> Right, but that is OK: It is a restriction at the data model level.  You are asking the application not to feed floats into the generic encoder.
>>
>> (Note that we strengthened the little wall between integer and floating point for RFC 8949, after seeing that RFC 7049 was confusing people a lot.)
>>
>>>
>>> So EAT
>>> - disallows half-precision in location, but allows doubles to relieve a decoder from implementing half-precision
>>
>> Bad.  Half-precision (binary16) is not a different type at the data model level, it is just an efficient way to represent certain numbers in your data model.
>> Binary16 has a significand [sic] precision of 11 bits.  Binary32 has 24 bits.
>> So if you feed random binary32 lat/lon (~ meter precision) to your generic encoder, every 8192th will be encoded in half-precision (*).
>>
>> Since lat/lon values are probably approximately evenly distributed, that by itself is not a reason to implement half-precision.
>> The fact that CBOR preferred encoding does employ half-precision is.
>> Deviating from that by disallowing binary16 is expensive: You no longer can employ generic encoders.
>>
>> Don’t do that.
>>
>>> - disallows float for iat to relieve a decoder from implementing float, assuming it is not implementing location (many EAT implementations will not support location)
>>
>> Good(**).  That selection of integer second timestamps is a part of your data model.
>> You can do that, and no generic encoder will suddenly turn your integer iat number into a float.
>> (Again, with RFC 7049, it possibly could have, but we fixed that.)
>>
>> Grüße, Carsten
>>
>> (*) Note that a similar thing happens in JSON: numbers that happen to be whole numbers will be encoded without fractional parts (10.0 becomes 10).
>> In certain decoder implementations, that makes them a different “type" than 10.0 or 1e1 or 0.1e2 etc., causing breakage.
>> But the JSON data model only has numbers, not integers as a separate, incompatible type, so these decoders are broken with applications that simply expect numbers.
>> (Find ISO 6093:1985 for some fascinating history in this space :-)
>>
>> (**) ((I’m not making any representation on whether applications need to know with a precision of smaller than a second when your EAT was issued.
>> I really can’t imagine that, but that is proof by lack of imagination; I do assess that the cost of enabling that is higher than the benefits.
>> But that is true until someone has a convincing counterexample…
>> Consolation is that these people can introduce a float iat = “fiat” :-)))
>>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats