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: spa...@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
