Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 08 July 2020 16:53 UTC

Return-Path: <rwilton@cisco.com>
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 831533A0F48 for <netmod@ietfa.amsl.com>; Wed, 8 Jul 2020 09:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iefszDHs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Bn6ZlS96
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 ffP0DyI56ksj for <netmod@ietfa.amsl.com>; Wed, 8 Jul 2020 09:53:55 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20053A0F39 for <netmod@ietf.org>; Wed, 8 Jul 2020 09:53:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5598; q=dns/txt; s=iport; t=1594227235; x=1595436835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2kxsmAyhhilGG3IYnxnGcryR2ZipLNqZz7vSQBvqCCQ=; b=iefszDHsEQCUJueRqkBg281GLLC78u70IfHmCa8ZCl3IsmjpK843lIIe Ejmc586NKu0oTOkSdsVqbfBDazwXbopJ7CuzNonIMmvv0yBLMZT8wt+Bh tr+JWzhmiLd9HFXZK8tU1+OfzM2gDiz+WqlE/Oi7ccDUtq+haf2HEMdjX s=;
IronPort-PHdr: =?us-ascii?q?9a23=3AMESeWBHFsHLWWqP7SUPPTJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401w+bX4zQ7PhfzvfQsr7tQ3cB/YfHvH1ROJBPVh?= =?us-ascii?q?pQj8IQkkRgBcOeEkT0IbbsaDByB8VNUlJpvhTZeUhYEcrzfRve93u16zNBGB?= =?us-ascii?q?z0MgBuY/nzG5Dfld+2y/H095CAKwlNjSC2NLV1Khj+pA7Nt84Q1I1lLKtUqF?= =?us-ascii?q?PJr3JEdv4Qy3lvIAeYng334YG7+5sw/g=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAB9+QVf/49dJa1dAxoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAUCBOAMBAQEBCwGBUVEHb1gvLAqHbwONVJh?= =?us-ascii?q?bgS6BJQNVCwEBAQwBARgLCgIEAQGECEUCghQCJDYHDgIDAQELAQEFAQEBAgE?= =?us-ascii?q?GBG2FWwyFbwEBAQEDAQEQKAYBASwLAQsCAgIBCA4CAQQBAQEeBQsbDAsdCAI?= =?us-ascii?q?EDgUIGoMFgksDLgEDC6AFAoE5iGF0gTSDAQEBBYE2AoNbGIIOAwYFgTMBgmm?= =?us-ascii?q?KAxqBQT+BEUOCHy4+gQSBWAEBAgGBNCofJoMCgi21EQqCXIhLkR+Cc4kzknw?= =?us-ascii?q?dm1qURgIEAgQFAg4BAQWBWgMwgVdwFTuCaVAXAg2OHjeDOjOEYYVCdDcCBgg?= =?us-ascii?q?BAQMJfIxpgTQBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.75,328,1589241600"; d="scan'208";a="520873252"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2020 16:53:54 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 068GrsYO025061 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jul 2020 16:53:54 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Jul 2020 11:53:54 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Jul 2020 11:53:54 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Jul 2020 11:53:53 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CIBI+uIKYx9x5VCuKRRZj7pIhDMSy2d5a/ajN5Taaxuk56E0q7rRyI8wNQOcKvlwsOJ1Xuhlvl6p0WzhunMjzV2ziQ/rPc0GN6VeQrVIT7keMYZ+7JKjOcKTzd91d+2lutY4D1/21sjIUtZxMVNwIUe1fBg044GBi0wSGs6nZtAwMFIvUgH4efXMY1nPCCUXgHSZBWy1TG/YydtFskivKc1vg+FZHMe7tGVQssm9ti9t4uBctzvKiR3u6vui9NIbboTDIRaqNHHedZiK0REhOLsZ/Nxn+jOXdh3P2JCcbD/Fot0QygyDiJJeT7SzBwO9bNMFjxvBGI5UTll1XmdHEg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dMtvr4l45AnhI0rSycD6+p4gJUb167ZF/uIVE8QGiVQ=; b=R4GKjnZc0T05R2PHkKT+Ce9949m9Rpt0RaxgD3PqvhjkqhZfUcEORH7Gu7zeF3MO6Y5ysYP59sybIvxFxNHsWhjxwsqO11COMDKvQV27FHLFPEgjsVGvnh3PfkThMV5qENzHELhp6Lsa8wX9w5AH2J1oku6NUpbBUsyE7T4euJaYlTVIEbiC7hd1vkU0hqatBp/EQwWMX8i4K+x/iaqRNl/2m60pZ123Qd/pakQ8CL559Of3u1IcVIF3MMZLzKx0RtgHqNUhXU/nUDemjuFwLU34LikxhQ9dCUuQKV37ieNUmEh7+BZ1KmywZZrLU+LGVpMiQoHCUKzyqBES+8f1Mw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dMtvr4l45AnhI0rSycD6+p4gJUb167ZF/uIVE8QGiVQ=; b=Bn6ZlS96fRh+tHQ089PW/wEFzocIoYwvdhV9wKrt3e/c3PJpYkg4bl63cfDQC/UBDOLIMbHFXRkaOBTHhHHrOeqNFBA1DveQavUSzF/wTNrzRY8MwD5rKGO/bsIdg0YkceM+mFcvj83LwZpZmtNpdex1aC5KKgVI45sGLzRjp8E=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4208.namprd11.prod.outlook.com (2603:10b6:208:17a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.27; Wed, 8 Jul 2020 16:53:52 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3153.031; Wed, 8 Jul 2020 16:53:52 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: Christian Hopps <chopps@chopps.org>, NetMod WG <netmod@ietf.org>
Thread-Topic: [netmod] Justification for decimal64 over string for floating point values in geo location data?
Thread-Index: AQHWVE64+Qz8HStWdUef/vPPn4qbG6j7+dcAgAHeZJCAAA0rAIAAAt2Q
Date: Wed, 8 Jul 2020 16:53:52 +0000
Message-ID: <MN2PR11MB4366A8C7ABA6A38496040DF1B5670@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <B548C4B4-2A97-4736-A6B2-358D1491D125@chopps.org> <20200707112450.wrttuprwrdr3nl5i@anna.jacobs.jacobs-university.de> <MN2PR11MB43660673154F85137B23C03BB5670@MN2PR11MB4366.namprd11.prod.outlook.com> <20200708164412.qbstkblscn4yxis6@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200708164412.qbstkblscn4yxis6@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.15.79.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3a3179fa-f31b-45c0-9d33-08d8235f7eab
x-ms-traffictypediagnostic: MN2PR11MB4208:
x-microsoft-antispam-prvs: <MN2PR11MB420839ADE6F5BC53B12DEB89B5670@MN2PR11MB4208.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04583CED1A
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gtFKqXl2G+K6W4BPt1JEe9OwiKSx5QQL8hQDejlTZvTKB4jxEatnrYsFPNkOvtJVUx9/PupnTrzRIfzAXyR5qW63EV+hXU/Y7dHh+6W9XFtQzjfjeGQ9liJHrVhxuQyIyHV4WJlGsKVHyJGHhVCK9Xr3Gi8h4+kr3+5nKqHHYuCFoCAtrCZ0eSq1urTZyDdFj9/F/02icBGt08TpIazVhXy2Nn0eoK3UW6ryYqxFrvbTOE+RxVTA6xA6B4dVVPJuGRH1d7OxJ4pvkNgWhiH005wIcPhiq+aMhLLo9P7zVHSDhIKjjARYNImgkqTJwNW0eUetDADEpaSpTv58yU6+wU1nraeTKok55B4NNfHHIu/ygXh+A5G8eCqyC/8cD2ZuE++nigJ4E6aYXsedqmcuVQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(366004)(376002)(346002)(52536014)(54906003)(2906002)(5660300002)(316002)(83380400001)(8676002)(33656002)(66556008)(4326008)(66476007)(64756008)(66946007)(66446008)(76116006)(26005)(55016002)(71200400001)(966005)(186003)(7696005)(8936002)(478600001)(6916009)(86362001)(53546011)(9686003)(83080400001)(6506007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 9v/7H3MK7xC3QPffnk0K2LUxFQNc2Rosz/qLe24NvOGfL6FffdPxcdqGN/yTi62HJC3lrlYUMT2lfIZSFzxZeP0S+cn2OYcQ/BnP7ZwRJcgQmatzbiFTTX1FhzvBmJGC1scqMhe3ECih9Y6EwOZXI8HVNLvPGH+r5ogJNlC1S/1Oakz5FNf752IASPHkNVc5PxvO5leZEsVelynfPPxxH/Ep4gWX3XmrvmbOebRzv+c18A6L5D1sR+GRSiyuN3AfRpx8BQt3Ev7LTu813ATjqj7j8l2gnGLV3LP3ox4mIpnvnfcgOqA6UFi9kp4nJ7N8kkQvs6h1I8M4Q3cns8RbPCIIf+MpsoMew3huRc+aMCc/XdsfMg45tzQMxd+wtCk8/8Uf8Ow6qa5wbF2q8mRgX3vBXj77yKNm7M7Sz3DRnb7bk4C0+UzeTOB8BolFLHbdRaUgsjHgK00FcLqqxmtw7FD/fK4WCvlwqRgLCbBo2z4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a3179fa-f31b-45c0-9d33-08d8235f7eab
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2020 16:53:52.2349 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yL88QJZs/BJG+Lbqn8YS0qlzVlTynBc1pJ6VnSj4rJAPNTfN77kZNGVujgqs/KeWoMiADYWRiMmF5I+Cx9aOrA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4208
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/JcNtLrYrVfXZyyk52vdK7o5JzG8>
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:53:59 -0000


> -----Original Message-----
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> Sent: 08 July 2020 17:44
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: Christian Hopps <chopps@chopps.org>rg>; NetMod WG <netmod@ietf.org>
> 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 <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/>