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

[David Spakes <[e-mail]>]

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.


    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:   [e-mail]
  SNMP Research                      voice:   [phone]
  3001 Kimberlin Heights Road          fax:   [phone]
  Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------