Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 08 July 2020 16:44 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4104B3A0F49 for <netmod@ietfa.amsl.com>; Wed, 8 Jul 2020 09:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4JkN3DEi-ZM for <netmod@ietfa.amsl.com>; Wed, 8 Jul 2020 09:44:17 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BF13A0F43 for <netmod@ietf.org>; Wed, 8 Jul 2020 09:44:16 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5D04734D; Wed, 8 Jul 2020 18:44:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id T3C1bfd4nioM; Wed, 8 Jul 2020 18:44:14 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Jul 2020 18:44:14 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0931A20154; Wed, 8 Jul 2020 18:44:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id tdmp0vHwPOC2; Wed, 8 Jul 2020 18:44:13 +0200 (CEST)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 807F4200E4; Wed, 8 Jul 2020 18:44:13 +0200 (CEST)
Date: Wed, 08 Jul 2020 18:44:12 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: Christian Hopps <chopps@chopps.org>, NetMod WG <netmod@ietf.org>
Message-ID: <20200708164412.qbstkblscn4yxis6@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Christian Hopps <chopps@chopps.org>, NetMod WG <netmod@ietf.org>
References: <B548C4B4-2A97-4736-A6B2-358D1491D125@chopps.org> <20200707112450.wrttuprwrdr3nl5i@anna.jacobs.jacobs-university.de> <MN2PR11MB43660673154F85137B23C03BB5670@MN2PR11MB4366.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <MN2PR11MB43660673154F85137B23C03BB5670@MN2PR11MB4366.namprd11.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/MwcSrC-0fOQkPBtAu-3JMhVPR8A>
Subject: Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 16:44:19 -0000
unknown precision != arbitrary precision /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 <netmod-bounces@ietf.org> On Behalf Of Juergen Schoenwaelder > > Sent: 07 July 2020 12:25 > > To: Christian Hopps <chopps@chopps.org> > > Cc: NetMod WG <netmod@ietf.org> > > 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 > > > netmod@ietf.org > > > 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 > > netmod@ietf.org > > 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] Justification for decimal64 over string … Christian Hopps
- Re: [netmod] Justification for decimal64 over str… Juergen Schoenwaelder
- Re: [netmod] Justification for decimal64 over str… Ladislav Lhotka
- Re: [netmod] Justification for decimal64 over str… Christian Hopps
- Re: [netmod] Justification for decimal64 over str… Juergen Schoenwaelder
- Re: [netmod] Justification for decimal64 over str… Christian Hopps
- Re: [netmod] Justification for decimal64 over str… Juergen Schoenwaelder
- Re: [netmod] Justification for decimal64 over str… Christian Hopps
- Re: [netmod] Justification for decimal64 over str… Juergen Schoenwaelder
- Re: [netmod] Justification for decimal64 over str… Ladislav Lhotka
- Re: [netmod] Justification for decimal64 over str… Juergen Schoenwaelder
- Re: [netmod] Justification for decimal64 over str… David Spakes
- Re: [netmod] Justification for decimal64 over str… Ladislav Lhotka
- Re: [netmod] Justification for decimal64 over str… Rob Wilton (rwilton)
- Re: [netmod] Justification for decimal64 over str… Juergen Schoenwaelder
- Re: [netmod] Justification for decimal64 over str… Rob Wilton (rwilton)
- Re: [netmod] Justification for decimal64 over str… Juergen Schoenwaelder
- Re: [netmod] Justification for decimal64 over str… Carsten Bormann
- Re: [netmod] Justification for decimal64 over str… Rob Wilton (rwilton)
- Re: [netmod] Justification for decimal64 over str… Don Fedyk