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: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
