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:35 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 769C03A0F24 for <netmod@ietfa.amsl.com>; Wed, 8 Jul 2020 09:35:12 -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=YufaORkc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GYaVmw0z
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 xhxfHCMRWCeb for <netmod@ietfa.amsl.com>; Wed, 8 Jul 2020 09:35:10 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6C63A0E77 for <netmod@ietf.org>; Wed, 8 Jul 2020 09:35:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4371; q=dns/txt; s=iport; t=1594226110; x=1595435710; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eNDPGkIeKKSuj4sEdrRJl4lELXAoWo2so23v0/7loyU=; b=YufaORkclERRGkTJmfZt8oD+yXuTERQaJO9kTEKL8JuniCuPql+g50LV IoEVbhvwzqmEq/sJUonSvlnn8+EXsCCpL5fioDKSUae+hKC4oIrryOBaY foOoRJpjtIN9sU+mLz3Ti8HOrPiYyHwRr0QXDTGhld/G3FUY+2zIPQRAE M=;
IronPort-PHdr: =?us-ascii?q?9a23=3AOG/GJBGuBJi7lRRajAT8v51GYnJ96bzpIg4Y7I?= =?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?A0AUAAAV9QVf/49dJa1dAxoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAUCBOAMBAQEBCwGBUVEHb1gvLAqHbwONU5h?= =?us-ascii?q?bgS6BJQNVCwEBAQwBARgLCgIEAQGECEUCghQCJDYHDgIDAQELAQEFAQEBAgE?= =?us-ascii?q?GBG2FWwyFbwEBAQEDAQEQKAYBASwLAQsCAgIBCA4CAQQBAQEeBQsbDAsdCAI?= =?us-ascii?q?EAQ0FCBqDBYJLAy4BAwuffQKBOYhhdIE0gwEBAQWBNgKDXBiCDgMGBYEzAYJ?= =?us-ascii?q?pigMagUE/gRFDgh8uPoEEgVgBAQIBgTQqHyaDAoIttREKglyIS5EfnyIdkT6?= =?us-ascii?q?KHJRGAgQCBAUCDgEBBYFaCSqBV3AVO4JpUBcCDY4eN4M6M4RhhUJ0NwIGCAE?= =?us-ascii?q?BAwl8jGmBNAGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.75,328,1589241600"; d="scan'208";a="786198312"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2020 16:35:08 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 068GZ85n004163 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jul 2020 16:35:09 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Jul 2020 11:35:08 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Jul 2020 11:35:08 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Jul 2020 12:35:08 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Iv4KiUTVVk1BXaIOhFUvJPss75Fhsrgls7D+h+j39kwxyaJY8BLOvyUEuMy1erS+JZMXZxwK9uwWSfMfmHbUP9o8GEnzZwXFlnS/QQUGOsGj1ykLb/NFtDbOiDCXBUnFeAiMrNIwVvEiPKzj6cTieY0L7ftitFEl0aM7IGfL1xa7FJTWOvAvOj2Qqk145EHSZcHROKyQQq8v47oAQ0bPdiDqFPFF7IQGgJ3AuP8GZLqpxy3lZ3yXUKthZ6m+8qjxoT9zGCdZOpBmb2mY9xl6wgjUoYxBbjiVaUytMZyT0hr+Vuubx/Lp32vU4eAE59f3lTYjHQ12p5P3qp4JXjmtkA==
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=Qt5+5Tpq8M7CZsZ3xYAeUZqPRox+iuiG658bphp4pfw=; b=Q8mkhBhgKUtx7yPu12odj5lKshMj98lQUv6gQicA2eXin4yLne2hSO/hwN3GNKm3Uf/fbuoLhEZyORHnB0/Vem37snWb93YNLCBwsyfef7zXPh9UpIY/YB28XQuraBzs1Kvl9sqPNCxXbltTC2BhErrrfAxZTAcoWctV4gDvu3pNu5Zhc6w9m0F1QyTo9Bz4TFzZXHHlMB3umo9K/s+N0H+asuMOD9cGN7B2tiK1Zf9WMRhgAh7BG0Lu+LetRZDerd9n3jAmYen0ORORG5Wm/ifcmmK0FvL0uaJvYlikj7iDCSqPdReUZlWYiUOcYS8wIXDfo2L62vsrFb6XQiWogQ==
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=Qt5+5Tpq8M7CZsZ3xYAeUZqPRox+iuiG658bphp4pfw=; b=GYaVmw0zHoPYcjo0wFSv874Y9A2MGzlIY1WcqcPPLuxT98RKJPofyqAhjlSK3kM0zmxawwMS/1O6UJASwBnhFISNDzH5tX49xN7OFWWQdBvQ7zg0uoXtGb9eoQV0sXj4HB/Q9VBQZrx7PdEbTWea+iDgkB464vgobF8fRBMAiL4=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4111.namprd11.prod.outlook.com (2603:10b6:208:138::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.22; Wed, 8 Jul 2020 16:35:06 +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:35:06 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Christian Hopps" <chopps@chopps.org>
CC: 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+dcAgAHeZJA=
Date: Wed, 8 Jul 2020 16:35:06 +0000
Message-ID: <MN2PR11MB43660673154F85137B23C03BB5670@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <B548C4B4-2A97-4736-A6B2-358D1491D125@chopps.org> <20200707112450.wrttuprwrdr3nl5i@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200707112450.wrttuprwrdr3nl5i@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: 680e18a2-90ec-475b-4044-08d8235cdf76
x-ms-traffictypediagnostic: MN2PR11MB4111:
x-microsoft-antispam-prvs: <MN2PR11MB4111BFC2545F974CDC50D2B0B5670@MN2PR11MB4111.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /fQgZ2xvpwHhSwkpyF0l/Gutic0/6/0NCujQy4VxdO2Jr4rlue8SpW2J5scT7fl2+qrj9SS6cm8s67etryM9l0T+euXDNtLg77t4EqNfx6WToJ/mbMD17UYa4RkGoHiQmBKWaGXR23gWJO8CbSQP4Or4nxUVS0U5/ubjVzy1cGy8wy0zhfVN6TpGnOQH+crKDAdYoHni1oVQ8I0YLCEpzhw0c93mwjzKkzUG8kOkmsY4UEWvV/dYJG+d8Us/8zOMhf6gk9w0jcQc7gB3S3ZoyzKK3fwu4p2usVzvnrdinQ/8LE+2ydFmdgxcyahed+Lcncw3fcXI1vXBjP7BwSsY1ZE810+y54dJSQX23L8ISv/IZV7OwGbiPW+7Vv/3RzVDqEd2suUwwgVg8lswCiglmQ==
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)(346002)(376002)(396003)(366004)(39860400002)(33656002)(66946007)(8936002)(2906002)(55016002)(9686003)(26005)(186003)(6506007)(71200400001)(53546011)(86362001)(4326008)(316002)(110136005)(5660300002)(52536014)(66476007)(76116006)(66446008)(478600001)(66556008)(966005)(64756008)(8676002)(7696005)(83380400001)(83080400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: BN4lMUd8bn8XdjAJ5iU0PCQxlwqm2Aso1rCp5ZD1DnaLoIjEt3SFwXzbdkZE7viGpoZTsAU1ZUpaUm3cweNzrBQR2MalxcDTRvzrWR16hbQR1Y7I0hm8rXw6JBrsB0EE+ipgfPaRchn2KOKRwE9KLy5xFXvSnO+LAvB32JSgh7N5oyhE0sQeG4Q4qCCXJB+6LrHX1CbpFNTK/KdzAHwTYQozus/qusZgcJOsg1SI5XpyyVJTrlsqfk/nL8/xpGHn9mxKsIvrCS6y2cVTaI2T0Kfn8nX+vMZ1BKhXkgyuaj8fQzRHhKgG7L0acxOVeRVh7ERMQGWYycCTap3Bk5CsBR8/ZnR88w1FV3etC7INEdtA6PfcSCI0dZ0gX/doKMF0HJ5HtnPYak69X0Nf2MnUMqcTCu1AkNrO/In/qOoZ4R4+sMaDlwnuDj1h05P2Xv1hyiylRACHX7tLEWdf5QJ2iEZ2gC95zy7FiyAGDa7hIpE=
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: 680e18a2-90ec-475b-4044-08d8235cdf76
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2020 16:35:06.2509 (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: tjil54xsrwnMlxHPItLT2Ab42llwCSt61958wZSQlKXXI2mvT6RRBvPUghSQB7SJp4EWhY8wTUFz0gJIW+OcFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4111
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/4iFIpBpCRwWZlPOlLgfYDTfWbcY>
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:35:13 -0000

[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