> -----Original Message-----
> From: Juergen Schoenwaelder <[email protected]>
> Sent: 08 July 2020 17:44
> To: Rob Wilton (rwilton) <[email protected]>
> Cc: Christian Hopps <[email protected]>; NetMod WG <[email protected]>
> Subject: Re: [netmod] Justification for decimal64 over string for floating
> point values in geo location data?
>
> unknown precision != arbitrary precision
[RW]
I agree. But don't follow the point that you are making. Please can you
clarify.
Regards,
Rob
>
> /js
>
> On Wed, Jul 08, 2020 at 04:35:06PM +0000, Rob Wilton (rwilton) wrote:
> > [As an individual]
> >
> > I agree with Juergen that in many configuration cases, using decimal64
> is better/safer than binary float/double. However, there are other
> scenarios, such as operational data coming from sensors, where
> float/double is probably more appropriate/useful, hence I would still like
> to see the next version of YANG supporting float/double, possibly
> restricted to operational data only.
> >
> > For configuration, with regards to the rounding errors alluded to below,
> I do have some sympathy with Chris's suggestion of support for arbitrary
> precision decimal numbers. It seems that more and more languages have
> native support for arbitrary precision decimal maths. I note that CBOR
> also has an encoding for them, and a JSON/XML encoding of them is
> seemingly trivial.
> >
> > Regards,
> > Rob
> >
> >
> > > -----Original Message-----
> > > From: netmod <[email protected]> On Behalf Of Juergen
> Schoenwaelder
> > > Sent: 07 July 2020 12:25
> > > To: Christian Hopps <[email protected]>
> > > Cc: NetMod WG <[email protected]>
> > > Subject: Re: [netmod] Justification for decimal64 over string for
> floating
> > > point values in geo location data?
> > >
> > > Precision often means different things to different people. Here is my
> > > take:
> > >
> > > - Floating point numbers have almost always rounding errors. And
> > > floating point numbers use binary fractions, a decimal fraction like
> > > 1.0 has no precise representation as a binary fraction. Type 0.1 +
> > > 0.2 into python or haskell or any other language that gives you bare
> > > floating point numbers and enjoy the result.
> > >
> > > - Fixed precision decimal numbers do not have rounding errors since
> > > they are essentially scaled integers and hence they are precise as
> > > long as calculations stay within the range.
> > >
> > > - Floating point numbers can cover a large number space (from very
> > > tiny to really big), fixed precision decimal numbers are much more
> > > restrictive.
> > >
> > > - In XML and JSON, numbers are rendered in strings that likely do not
> > > look much different if its a decimal64 or a float or ... If you
> really
> > > care about size, use a binary encoding like CBOR.
> > >
> > > /js
> > >
> > > On Tue, Jul 07, 2020 at 07:06:20AM -0400, Christian Hopps wrote:
> > > > I received feedback in my YANG doctor review (thanks Mahesh)
> regarding
> > > the use of decimal64 for most of the values in the geo location
> grouping
> > > (https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04). In my
> > > comparison sections I note that some precision (at the very extremes)
> may
> > > be lost when converting from other geo location formats that use
> string
> > > (or double for w3c) to decimal64. Given that mention of loss of
> extreme
> > > precision, the reviewer was asking if some justification for the
> decimal64
> > > should be given in the document.
> > > >
> > > > What are the advantages to using decimal64 for floating point
> numbers vs
> > > using a string with a pattern "[0-9]+(\.[0-9]+)?" (convert that to
> yang
> > > pattern language). The advantage of using a string is that the
> precision
> > > of the value is not restricted by the model. Does the YANG decimal64
> > > values have a concise binary format that can be more efficiently
> > > transported or stored in binary form? If so is this the only
> advantage,
> > > and is it enough of one to limit the precision in the model?
> > > >
> > > > It's definitely worth noting that the precision of the decimal64
> values
> > > seem vastly adequate for geo location data (e.g., for Cartesian
> > > coordinates and height values which are measured in meters the
> fractional
> > > digits is 6 which means the surface could be up to 9 billion
> kilometers
> > > large (or away from for height) and the precision is to the
> micrometer.
> > > For ellipsoidal coordinates there are 12 fractional digits for the
> > > degrees.
> > > >
> > > > Thanks,
> > > > Chris.
> > >
> > >
> > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > >
> > > --
> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
