Re: [core] [Last-Call] Last Call: <draft-ietf-core-senml-more-units-02.txt> (Additional Units for SenML) to Proposed Standard

[Hytonen Harri <[e-mail]>]

Hi Carsten,

Integer value measurements using unit "something per hour" needs to be converted into floating point and scaled to "something per second". The receiver of the measurement then receives a floating point, scales it back to "something per hour" and presents it as a floating point value since it has no information that the original value was an integer, unless that information was passed in meta data. Also, if the transmission bandwidth is constrained, integer would be less costly.

BR,
Harri     
 

-----Original Message-----
From: Carsten Bormann <[e-mail]> 
Sent: Thursday, 31 October, 2019 10:37
To: Hytonen Harri <[e-mail]>
Cc: core <[e-mail]>
Subject: Re: [Last-Call] [core] Last Call: <draft-ietf-core-senml-more-units-02.txt> (Additional Units for SenML) to Proposed Standard

(Limiting CC list to CoRE WG:)

> On Oct 31, 2019, at 08:17, Hytonen Harri <[e-mail]> wrote:
> 
> As explained before, it's not matter of saving floating point calculations, but preserving the original precision of the measurement. 

I think this is an interesting statement.
This certainly was not the reason why we were going for the secondary units (as Ari said, these are about support for legacy data models).
But I’m still curious how, say, expressing precipitation in mm/h is preserving the precision better than expressing it in m/s after scaling it by 3.6e6.  Sure, that floating point calculation has a rounding error, but that will usually be on the order of 1/2**24 (or 1/2**53 if your sensor has double precision floating point), while the instrument resolution is likely on the order of 1/2**10 or 1/2**12 (as you can see, I know nothing about precipitation sensors).

Note that formats such as CBOR or JSON cannot *indicate* precision or accuracy (or uncertainty in general) within a single number; there is no way to say what conventionally is written down as 8.0 vs. 8.000 (even in JSON, where both forms can be written, these have exactly the same semantics).  So that would be a separate issue (easily addressed by putting information about the uncertainty into separate numbers, often in the metadata as it often doesn’t change between measurements).

Note also that the terminology here often requires clarification or explicit referencing; e.g., IEEE 754 uses “precision” essentially for “resolution”, not for “precision” as used in metrology(*) (which is essentially “repeatability” and “reproducibility” in the VIM [1]).

Grüße, Carsten

[1]: https://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf
“International vocabulary of metrology — Basic and general concepts and associated terms (VIM)”

(*) applying metrology to meteorology sensors :-)