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

Ladislav Lhotka <ladislav.lhotka@nic.cz> Tue, 07 July 2020 14:59 UTC

Return-Path: <ladislav.lhotka@nic.cz>
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 988433A0D7C for <netmod@ietfa.amsl.com>; Tue, 7 Jul 2020 07:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 9j1e-n3nof93 for <netmod@ietfa.amsl.com>; Tue, 7 Jul 2020 07:59:46 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C360F3A0D76 for <netmod@ietf.org>; Tue, 7 Jul 2020 07:59:45 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1::380] (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 396FB1409B9; Tue, 7 Jul 2020 16:59:43 +0200 (CEST)
To: David Spakes <spakes@snmp.com>, netmod@ietf.org
References: <B548C4B4-2A97-4736-A6B2-358D1491D125@chopps.org> <20200707112450.wrttuprwrdr3nl5i@anna.jacobs.jacobs-university.de> <85c0def4-b82a-d58a-0694-05fd6df90bcc@nic.cz> <alpine.BSF.2.00.2007071025350.23266@mainfs.snmp.com>
From: Ladislav Lhotka <ladislav.lhotka@nic.cz>
Autocrypt: addr=ladislav.lhotka@nic.cz; keydata= mQINBFhU5JIBEACmGIeLglGrwf6JBcNrcLoO19yAdKcH7V132STGHlhEAgmdzwclgVE7GN7y 5+1ySQ8jhDM80QSQ+XaXsSbHTQl23vcVvSfKNdme11kGEQ7kO/bTbUYxpRRa5dqDjLeEHhol WiNk6nUHqEAExbpEoITiO216Lwxh8gD2+39ZH/UVJgMHoZD1VmrxHSnp9b1SpmDWkbILRc93 u6lADieU67SG5vWqGaBgp8JQAVI3F+ZhcLXHQiQLPliePT3YKfvubWg9NIprts9fv2JAUywv NN4R5gg1oFegOXouzlBySiUNXndzJsj1JAcI4psGA9iGYBhgdILXg+2Kwkok9rrx1gWsqtmb lcFDiJRx52FUohHz9obZ9gkOd4NoV4jatjnu+9HKA8V2T5JUgTCgOWeI2yHoSNFJvKO0ygIg /5ccrB9iRdmJIiA2cAmu5MaHnKxAcQ7eaXqQN+JRcpFUH2ooFHKm0750U3aAZY3an5+a5Njh XddaDDX/7f0a68jaWuoKFn7Mqa2HhNnLJs2Nsq9quLdWEUh59wOgTrp2TZnkAFtG1MGa2dNz M3YX22+jwbnfv/U72fEu33juXfMLWfwzJEzQG47dnpmsArt8fM+atOvTSvkLQDNJkOSVZT8m NR5/OeIYfxhe3FUSrljRQBXN8ioVoiMtcCR8EKXCwCnja20vdQARAQABtChMYWRpc2xhdiBM aG90a2EgPGxhZGlzbGF2Lmxob3RrYUBuaWMuY3o+iQJUBBMBCgA+FiEEtr1TxpCtJF8Aid5X uPkrCKn3bGcFAl3k3q0CGwMFCQecs7wFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQuPkr CKn3bGeXZA/+IM3zgfkMwQ+rvYMEn1cHoYwA0j8iwGtQp6FQYO/Vj0d6Q07Q5/iUqM0UuniU HN6xC5APrPsxwyeSuJUW1zjGm6JD8U5WinbNJuBU/FMC7XyHgOwwXdlT1bLlhOYnvUrZx0bB QeMLnUinvTHLVFnpUCfFpyKRUKh3kkUJS5AXRz5ZgEqJUr79GSTg46dluXlz9mnPIkwluwYO ydlhtW/+s/xVuCIqRUdhhc30d8K5XB+smiYmHSzePjLGwsP1pHt1e8we57EFNvm7iiwXPCAI cy+PAtCxmq2zsIxsZxtZP4SWbRcj2Z16XTtT+hhNK6SWKhpDuacadpWChXpYc36xtuJ5Ll3C lZqa/6mDRcagJy016pQboW/4JIkFcFhu6ugNwvR1OBom04VPVBxqQRgazqpfkB0jSWWS4rwh l30kwDFW5eWcski3Ja5g2drj0YpUeEkMOQcToxLPXffI6dauKTMh7K6RF++LGCYxOukWt2r+ jk6/pB3rSVztAJDb4kc/EgE7yNwrVQOxkKHfk3rGCXkvijCgU3jS0k5g01/OwENxpEUk0Nln mlLJdb8Bju6Jp2y3ZX97+Szs2tH8M6Mpny213lFgc4EVCOFVtIPsyYfiR9On1IIdRqMx3mQC 5AV+3Wc0o3M7Ku0ZbuhkYLNIhlNrRjlxFRk12FpZwFwznY+5AQ0EWFTnYgEIAM6XJ37HGp7H nzztkWbCW+5zkLzff2LQh7yoH32CGJTK7vnQKOY+JKi16lR1qUDHOUtYfRj17jBNWaB0CY0k qkRWCDXG0pff8VT63Kg/DlS2LLbPQpO2NcjdMhPTTUadnKWeo7h6/mFF7VW4X2sm1NYeNWD5 VQxdPQUbnCJ4Pi23QZRJnBu2ycM9aXa7ERRvpN3i3mAc2UgkJWq4KGjI74cd7ytCsU0RN6RT S0sFE4zCB1r6nXqfHHiousATS6+3GnuIGTtaeR0nXHlIvl2AC91+hswsWaA7YB4dB2/GJ8PN L3d07gA6yR2DoZJZhAmtMUiUzap4jgf07UoTOY80MHkAEQEAAYkDcgQYAQoAJgIbAhYhBLa9 U8aQrSRfAIneV7j5Kwip92xnBQJcLzGrBQkHnLFJAUDAdCAEGQEKAB0WIQQ+THLKBBuTzVYa 3ozuYRDCyLOtngUCWFTnYgAKCRDuYRDCyLOtnhnlB/49PV5puyMGBJXY5XBdaPIKFfC5eBfy EOgMqDfJS9yhV7bhFRzzztX9Z7COod6mxmlogNaDFMk/yFH25DOe2tpjKs6sqa9bwyY3cOFw pp38VdeAq0FxF3qOhjKzF12RVQ4Ipu/ahzzQ6V5reia+onOghw+BrjOsPExJaDbiif5UqL/F yWvERlR46GGbFzK9gEvUo+52Wjx3t4hW2IMZKS58xvzkMkTQtxYHAM++jO7bH18wV603JJC3 mZxq9YKKFHVcxinp9l8yzVxfIjhiklednvb30lggY4VEG6X+BER/lcw1QgSDojjbHY72o+76 rBYZ+pSacY/idn5AkAEkQyxsCRC4+SsIqfdsZ1aAEACjuN1b73KNsdsNZuV/MSdmfC+LkoG2 +20kGWzHHiq1Owc4W3fDRohJThM5xyKt2RAcLZAqzfeef1AuoESTqqR6OheaF3u0HAa+U87E /dfjflBOsGZloNi/0/JcN2B8VJpXBwA55adA4YwNL/i8k/roIZ0Yh4wd8Bv8G4exrjvPZPCG klGNBvIJomaqgb9YDvdN22CW3f0zoCwdTX+XV7YL6IQsZroRViLWZv12UCKO1kVop8IMQolx XGbo4kVkqtVx0A4O+ZqCiG819QGZIAtaKSG6aK1xWxNg16ClbEoCEglPeLiOr1ttibO6emuK 4w+4vA5nu+q5niUZ611f/9OtnNO6w/EZ9jRjiqBbo7esNkzal4LjwZUa0B3poWRz+7B++CYS F0c/qdfqjYmiN4IEbXnC0EFhwOYejTayy/H/nA0yGjxF7xA2Krom8B3YTaOnaZ2lVx0gtQK6 Ih7SSc842yRyBnMoVko8mzcHb/0urD2uWkPI5VfXLF9OJhfe3J1xswtqfOxFtf1cZv6fnQID 4gfsvRP8s8Wow5m3gp1HLSlxeZcc57nK8/nKWaTssdOf6doSw8kLWC5Dcwx2Ld15SsjkHeCO MtOaIxq+Er6vnvcepj76pZZJznS/bMriYPyyw0FIYmAPcnm3v5W+HZ339ktp+Kk3fNl3qJo6 C+Sjv7kBDQRYVOgGAQgA0GW5sWxqhcD9hxi/LQZ/hzPBgrpTvyIgxHrJN1HZ2BzdpNU7UlnC DVDzvAV2/1kEIiCdTYnnly0+PCHhyEdP45M9//oH7KYd/F/JSQwI+56mGP2O0fBBu9WStHws RraGfzGGZDV1XutvIz/qzpkBGpXGzA73Bi2Xye+/9JtHXmjhoXnItQLO38Hqnb5kXk79cSC4 TStPAKdrB/CMolcArT8j9eijIUOPMkWCGCeICv/hECpA5CZma2tplU80cKiOIYknFG8E+5Pr FlW962P7njIaahWSIObM2/C48uu5KAwgyDj6DA14cwc/4wfRsXZFjUMNpI0xer1iLQV5y1vi 6QARAQABiQI8BBgBCgAmAhsMFiEEtr1TxpCtJF8Aid5XuPkrCKn3bGcFAlwvMc8FCQecsMkA CgkQuPkrCKn3bGfkEg//alC3LNxnyH3tNy/OKQqOFJLUCidIm77DT/ZQfjLMAZezzCAq1Adf hVg7uV5a/dFdQdVDnjEz+SQ6/EzyqGashdAMnlBDwiqPe3MhB0L97VQwjNQa0wf1AsHdQCv8 i3e7U6RjlEmSC42dA+RjhrFOCZPtUTlCVDoSnY1S0kZOvEjhHvw901MPEINikZY4TBc18Xnk fbGQhglvI9NqBawlBKHyDGTAVJL7ld60iHsWt3prq+h48iFjc7x2JT39oBxT5Jhl3pg01QSC vu2Fg99vUuRr3u8tavnMKX4Vk3bujpHhuyOTSm0X37nwwu9DpMqkeUNvYR2RM+EuGGltonrN yrb5S21omN7fLDvRtdUBUOCFJLxZunTDLlkig/QuT+QlW7CG59Ussuu37HxgpiICCeeBDOaF bkZku43Qwt5cTtdJ8BkzYgvvoC7NegBn9N+U+Etrrvs09Slo11wlQx1F3sk9T9rjz1QrPM8j blxEgepm+W75VJ22z1qY/JnNElygR7KeTaeOY+iCn4wgDeC964AHMuGzG7aUg8P3zjgClL1T pFJwQUml880L6C+VuWPxuFIS18BPCYtLGlfQc5jp4dGN87ftenT13W70XiGXdrmIAFBF6Jjk 3huuDoRvdbPavAGdxu5QGdHeH0/GjfTxq7lRwgamoY0lw1LIB6LOzXo=
Organization: CZ.NIC
Message-ID: <eae9525a-7e78-ef7c-8d26-c443a0724583@nic.cz>
Date: Tue, 07 Jul 2020 16:59:43 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <alpine.BSF.2.00.2007071025350.23266@mainfs.snmp.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6HeoxngXlyPWhnLlxmvILd3z5yA>
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: Tue, 07 Jul 2020 14:59:49 -0000

On 07. 07. 20 16:40, David Spakes wrote:
> Like Lada, I know nothing about geo-location formats.  But this
> discussion sounds familiar because it keeps coming up time and
> again.  There are arguments for and against decimal64, and people
> have before expressed a need for a variable-precision type.
> 
> I proposed the following compromise/solution in 2009 and again in 2014.
> Now, I'll propose it again: a derived type that solidifies the
> position/preservation of decimal64 and builds on it to deliver the
> desired feature.

This type might be much more useful if the effective union member could
be determined from the data. It is often important to differentiate
between 1.23 and 1.230, but this wouldn't be possible here, due to the
canonical form for "decimal64" (sec. 9.3.2 in RFC 7950).

Lada

> 
> 
>    typedef real {
>      type union {
>        type decimal64 {
>          fraction-digits 18;
>          range "-0.999999999999999999 .. 0.999999999999999999";
>        }
>        type decimal64 {
>          fraction-digits 17;
>          range "-9.99999999999999999 .. 9.99999999999999999";
>        }
>        type decimal64 {
>          fraction-digits 16;
>          range "-99.9999999999999999 .. 99.9999999999999999";
>        }
>        type decimal64 {
>          fraction-digits 15;
>          range "-999.999999999999999 .. 999.999999999999999";
>        }
>        type decimal64 {
>          fraction-digits 14;
>          range "-9999.99999999999999 .. 9999.99999999999999";
>        }
>        type decimal64 {
>          fraction-digits 13;
>          range "-99999.9999999999999 .. 99999.9999999999999";
>        }
>        type decimal64 {
>          fraction-digits 12;
>          range "-999999.999999999999 .. 999999.999999999999";
>        }
>        type decimal64 {
>          fraction-digits 11;
>          range "-9999999.99999999999 .. 9999999.99999999999";
>        }
>        type decimal64 {
>          fraction-digits 10;
>          range "-99999999.9999999999 .. 99999999.9999999999";
>        }
>        type decimal64 {
>          fraction-digits 9;
>          range "-999999999.999999999 .. 999999999.999999999";
>        }
>        type decimal64 {
>          fraction-digits 8;
>          range "-9999999999.99999999 .. 9999999999.99999999";
>        }
>        type decimal64 {
>          fraction-digits 7;
>          range "-99999999999.9999999 .. 99999999999.9999999";
>        }
>        type decimal64 {
>          fraction-digits 6;
>          range "-999999999999.999999 .. 999999999999.999999";
>        }
>        type decimal64 {
>          fraction-digits 5;
>          range "-9999999999999.99999 .. 9999999999999.99999";
>        }
>        type decimal64 {
>          fraction-digits 4;
>          range "-99999999999999.9999 .. 99999999999999.9999";
>        }
>        type decimal64 {
>          fraction-digits 3;
>          range "-999999999999999.999 .. 999999999999999.999";
>        }
>        type decimal64 {
>          fraction-digits 2;
>          range "-9999999999999999.99 .. 9999999999999999.99";
>        }
>        type decimal64 {
>          fraction-digits 1;
>          range "-99999999999999999.9 .. 99999999999999999.9";
>        }
>        type enumeration {
>          enum overflow;
>          enum underflow;
>        }
>      }
>      description
>        "The real type defines a large, finite set of real numbers with
>         varying degrees of magnitude and precision.  An object of type
>         real is able to express configuration and state data as any of
>         the real numbers in the set.  The real type is suitable for
>         applications that deal with ratios in which the decimal point is
>         not fixed to a single position.
> 
>         Positive numbers larger than 99999999999999999.9 in state data
>         SHALL be represented as an overflow.  The enumerated value
>         overflow is not valid for an <edit-config> operation.
> 
>         Negative numbers larger than -99999999999999999.9 in state data
>         SHALL be represented as an underflow.  The enumerated value
>         underflow is not valid for an <edit-config> operation.
> 
>         Real numbers between -99999999999999999.9 and 99999999999999999.9
>         (inclusive) having a combination of magnitude and precision that
>         falls outside of one of the range substatements in the union--
>         including irrational numbers such as 'pi'--may only be
>         represented by the real type through rounding or truncation.
>         For example, pi could be rounded (up) to 3.14159265358979324 or
>         truncated to 3.14159265358979323 to preserve as much of the
>         precision information as possible.  Note that an application
>         could choose to round (down) the value of pi to 3.14 or truncate
>         the value of pi to 3.14.  This specification does not define
>         rules for the rounding or truncating of such values, considering
>         these decisions to be application-specific.";
>    }
> 
> 
> 
> David Spakes
> 
> 
> 
> On Tue, Jul 07, 2020 at 08:27:19AM -0400, Christian Hopps wrote:
> 
>> Mentioned in the earlier mail
>>
>> instead of
>>
>>     "decimal64"
>>
>> use
>>
>>     "type string { pattern '[0-9]+(\.[0-9]+)?'; }"
>>
> 
> 
> On Tue, 7 Jul 2020, Ladislav Lhotka wrote:
> 
>> On 07. 07. 20 13:24, Juergen Schoenwaelder wrote:
>>> 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.
>>
>> I know nothing about geo-location formats, but I suspect that the string
>> representation is based on some assumptions regarding the underlying
>> numeric type. So one option might be to define a new type derived from
>> "string", and specify these assumptions in the description.
>>
>> Lada
>>
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
> 
> 
> -------------------------------------------------------------
>  David Spakes                       email:   spakes@snmp.com
>  SNMP Research                      voice:   +1 865 573 1434
>  3001 Kimberlin Heights Road          fax:   +1 865 573 9197
>  Knoxville, TN  37920-9716  USA      http://www.snmp.com
> -------------------------------------------------------------
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67