Subject: Re: [netmod] float vs. decimal

From: David Spakes <[email-masked]>
Date: Thu, 14 May 2009 13:03:34 -0400 (EDT)

Over the past couple of days, I have been working on implementing
decimal64.  I like the simplicity of the design that it is basically
a signed 64-bit integer with the extra bit of information to tell you
where the decimal point belongs.  I don't particularly like the fact
that the decimal point is always located at a fixed position for a leaf.
Also, I find it unsettling that the upper and lower bounds of
representable values are not nice round numbers (not base-10 boundaries).

I have been experimenting with a construct that builds on decimal64 to
allow one to represent numbers where the decimal point can move around.
I want to propose that it be added to the "yang-types" document.
Description follows, below.

On Sun, 3 May 2009, Andy Bierman wrote:

> David Spakes wrote:
> > Largest positive value that can be represented in a decimal64:
> >     922337203685477580.7
> >
> > Largest negative value that can be represented in a decimal64:
> >    -922337203685477580.8
>
>
> I think the ranges are different for each value of fraction-digits:
>
> fd         min                       max
> ---------------------------------------------------------
> 1      -922337203685477580.8        922337203685477580.7
> 2      -92233720368547758.08        92233720368547758.07
> 3      -9223372036854775.808        9223372036854775.807
> 4      -922337203685477.5808        922337203685477.5807
> 5      -92233720368547.75808        92233720368547.75807
> 6      -9223372036854.775808        9223372036854.775807
> 7      -922337203685.4775808        922337203685.4775807
> 8      -92233720368.54775808        92233720368.54775807
> 9      -9223372036.854775808        9223372036.854775807
> 10     -922337203.6854775808        922337203.6854775807
> 11     -92233720.36854775808        92233720.36854775807
> 12     -9223372.036854775808        9223372.036854775807
> 13     -922337.2036854775808        922337.2036854775807
> 14     -92233.72036854775808        92233.72036854775807
> 15     -9223.372036854775808        9223.372036854775807
> 16     -922.3372036854775808        922.3372036854775807
> 17     -92.23372036854775808        92.23372036854775807
> 18     -9.223372036854775808        9.223372036854775807

The construct I am proposing is a typedef of a union of eighteen
decimal64 types, one for each of the possible values of fraction-digits.
I have been calling it a "float", but readers should please jettison the
connotation that this word carries about representing arbitrarily large
or arbitrarily small positive and negative values via a mantissa and
exponent.  I only use this word to the extent of the meaning that the
decimal point can move around within the value.  If the working group
chooses to use this construct but  call it by another name, another
possibility that comes to mind is "real".  Here it is:

  typedef float {
    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";
      }
    }
  }

Using this construct, neither application writer nor the author of a
YANG document need take into consideration how many fraction digits
are needed for a particular leaf.  The position of the decimal point
is determined implicitly by the number of digits in the whole-number
part of the value.  The more digits you need to use to represent the
magnitude, the fewer digits you have left over for precision.

The above definition for a "float" seems cumbersome, but I believe most
application writers will find that the semantic is familiar and
comfortable.  To demonstrate what I mean, here is a simple illustration.

   The behavior of this construct is very much like that of any common
   calculator (either a non-scientific calculator or a scientific
   calculator in non-scientific mode).  Mine has a 10-digit LCD display.

   If I press the key for pi, the screen shows 3.141592654.  This is
   not all of the digits for pi, but the calculator can only hold
   ten digits.  The magnitude requires one digit, leaving nine digits
   for precision.

   If I press 'x' '10' '=', now the screen shows 31.41592654.  The
   magnitude now requires two digits, and so we lost one digit of
   precision.  The same digits are on the screen...the decimal point
   just floated to its new position.

   One can imagine a leaf that is type "float" as working like a
   calculator having an 18-digit display.

The purpose for the range substatements is also for comfort level.  An
opinion expressed in conversation both by me and one of my coworkers
was that decimal64 feels "weird" because the range of values does not
end on a base-10 boundary.  The range provides upper and lower bounds
on a base-10 boundary by sacrificing one digit of magnitude.
For example:

                                 The largest positive value that can
                                 be represented by a leaf that is a
     922337203685477580.7   <--- decimal64 with fraction-digits 1.

      99999999999999999.9   <--- The largest positive value that can
                                 be represented by the float construct
                                 described by this proposal.

If this proposal is acceptable to the working group, I would offer to
formalize the text of the description unless the document editor would
prefer to do that.

Regards,

David Spakes

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 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
-------------------------------------------------------------

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 14 May 2009 10:14:03 -0700

Hi -

> From: "David Spakes" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, May 14, 2009 10:03 AM
> Subject: Re: [netmod] float vs. decimal
...
> I want to propose that it be added to the "yang-types" document.
..

Care to comment on the pros&cons of this with respect to IEEE float,
particularly regarding matching in xpath?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 May 2009 10:26:59 -0700

> Description follows, below.

We already two of those 'decimal point moving around' things,
and we took them out.  I think decimal64 is good enough,
because fixed point is really good enough.

It might be better for decimal64 if it did not utilize
the entire value-space, so that the clean ranges you
defined in your union could be the built-in range limits.
I do not think the ranges currently supported are intuitive,
but the YANG compiler will catch any error immediately,
so it is not a big deal.

There is still an issue with the canonical form:
with all the fraction-digits or with trailing zeros trimmed.
Your union typedef relies on the exact number of
fraction digits being used every time for a given object.
The current canonical form (remove trailing zeros) breaks
your 'float' data type.

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> 
>

---

From: David Spakes <[email-masked]>
Date: Thu, 14 May 2009 13:38:03 -0400 (EDT)

> particularly regarding matching in xpath?

I would defer to others more experienced with XPath to offer their
comments.

I was just re-reading the conversation between Martin, Andy, and
David Parain from early February about the desire to be compatible
with existing technology.  If there is compelling reason to limit
the number of digits after the decimal point to 14 to be friendly
with the IEEE representation, then the decimal64 members of the
union with fraction-digits values of 15-18 could be deleted, as
shown below.

Regards,

David Spakes

  typedef float {
    type union {
      type decimal64 {
        fraction-digits 14;

On Mon, 9 Feb 2009 [email-masked] wrote:

> I did some experiments:
>    - %.14f seems to be safest, although sometimes 15 decimal
>        places of precision is OK.
>    - the only glibc option that matches YANG and XPath is %f,
>      and you have to manually remove trailing zeros and maybe
>      the decimal point as well.
>    - strtof is broken in glibc, so float32 is quite problematic.
>      strtod works fine, so 'double' is not affected, just 'float'.
>      (try strtof('1.3')).
>    - I prefer to use the glibc names for inf, -inf, and nan,
>      instead of inventing new terms.
>
> Attached is a terse summary of the precision issue (x.c and its output)
...

---

From: David Spakes <[email-masked]>
Date: Thu, 14 May 2009 13:57:56 -0400 (EDT)

> because fixed point is really good enough.

Earlier this year, I wrote code to implement float32 and float64.
For testing and demonstration purposes, I created a simple example
which was, in fact, a FLOATING-POINT-CALCULATOR module.

When the decision of the group was to eliminate float32 and float64
in favor of decimal64, I changed the code to implement decimal64.
However, when I proceeded to update the example for decimal64, I
found that it really didn't fit anymore.  Instead, I created a new
and different example to demonstrate decimal64.  However, this
exercise got me thinking.  If decimal64 wasn't a nice fit for the
data in the very first example I created, I figured there were
likely to be applications in the field for which decimal64 would
also not be a good fit.

What I am proposing is just to formalize something that is already
completely legal to do in YANG.  Anyone can make a union of multiple
decimal64 variations.  My assertion is that it would be better for
everyone to use the same flavor of 'decimal point moving around' thing
than for everyone to invent their own.

By formalizing the float/real typedef of a union now, any potential
XPath concerns can be addressed.

> fraction digits being used every time for a given object.

I don't understand what you mean.  Since the float/real proposal
is just a union of decimal64, the conanical constraints that apply
to any individual member of the union would apply to the whole.

> The current canonical form (remove trailing zeros) breaks

How?  If a leaf is defined to be of type float/real, and if the value
is "52.3", that value could be assumed by any of the decimal64 members of
the union with fraction-digits values between 1 and 17 inclusive, and
therefore it would be legal for the leaf.  What does it matter that
the data could equally fit more than one union member?

Regards,

David Spakes

---

From: David Spakes <[email-masked]>
Date: Thu, 14 May 2009 14:06:52 -0400 (EDT)

> the data could equally fit more than one union member?

Correction: between 1 and 16 inclusive.

Regards,

David Spakes

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 May 2009 11:14:07 -0700

> the data could equally fit more than one union member?

If the user enters 99991.00000000000000, will it
be detected as an overflow, or not?  Will the
agent trim the zeros to 99991.0 (canonical form),
so it appears valid (99991 within range for fraction-digits 1).

What if the user changes the value to 99991.00000000000001?
Then it becomes an error, instead of just matching
the wrong union type member.

If the agent allows the range to keep changing,
every time the leaf is modified, just like a float,
then we should just use the IEEE 754 data type for that.

Andy

---

From: David Spakes <[email-masked]>
Date: Thu, 14 May 2009 15:11:09 -0400 (EDT)

On Thu, 14 May 2009, Andy Bierman wrote:

> be detected as an overflow, or not?

Since there are five digits of magnitude (9-9-9-9-1), there are thirteen
digits of precision available.  The union member that best fits this
data is:

      type decimal64 {
        fraction-digits 13;

You specified fourteen digits after the decimal point, which is greater
precision than the type can represent.  The choices are to round or
truncate.

> Will the

I am not a participant in the thread discussing the canonical form
of decimal64.  I would defer to one of the participants in that
discussion to answer your question.

I will observe that my 10-digit LCD non-scientific calculator prefers
the canonical form if I enter 99991.00000 and press '='.  :-)

> What if the user changes the value to 99991.00000000000001?

You specified fourteen digits after the decimal point, which is greater
precision than the type can represent when there are five digits of
magnitude.  The current choices are to round or truncate.

> the wrong union type member.

If a module were to define a leaf of type float/real,

     container numbers {
         leaf ratio {
             type yang:float;
             config true;
         }
     }

and if the agent were to receive an <edit-config> message with the
above value for the leaf,

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <numbers xmlns="http://example.com/schema/config">
             <ratio>99991.00000000000001</ratio>
           </numbers>
         </config>
       </edit-config>
     </rpc>

then I would agree with you this is an error.

If the application underlying an agent were to contain a value
99991.00000000000001, that might be fine for the application, but
the agent could not represent the value in a float/real leaf with full
precision.  When the application delivers the value to the agent in
response to a <get> or <get-config> message, the value would need to
be rounded or truncated by either the application or the agent.

If neither rounding nor truncation were an acceptable operation for the
leaf, then I suppose the situation would be an error condition.  Are you
suggesting that in this case the union should have one additional member,
like this?

      type enumeration {
        enum overflow;
        enum underflow;
      }

> then we should just use the IEEE 754 data type for that.

I'm not a proponent of using the IEEE data type.  I like the decimal64
concept a lot, I just think there needs to be an option so the decimal
point isn't permanently fixed to one position of a leaf.  The float/real
union is my compromise proposal.

If the possibility exists that someone may argue to reintroduce
float32/float64 as a built-in type in a future version of YANG, then
perhaps it would be best to call the typedef union of decimal64 that I
am proposing "real" instead of "float".

Regards,

David Spakes

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 May 2009 22:42:46 +0200

On Thu, May 14, 2009 at 09:11:09PM +0200, David Spakes wrote:
 
> perhaps it would be best to call the typedef union of decimal64 that
> I am proposing "real" instead of "float".

For me, this proposal is neither a "real" nor a "float" but a "hack".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: David Spakes <[email-masked]>
Date: Thu, 14 May 2009 18:25:25 -0400 (EDT)

> For me, this proposal is neither a "real" nor a "float" but a "hack".

In response to other comments I received both on and off the list, I would
like to amend my proposal to call the typedef of the union "real".

There is too much baggage associated with "float", and I prefer "real"
over "hack", thank you very much.

> What if the user changes the value to 99991.00000000000001?

Thinking more about the union, I considered this text near the top of
Page 131 of draft-ietf-netmod-yang-05.txt:

  "When a string representing a union data type is validated, the string
   is validated against each member type, in the order they are
   specified in the type statement, until a match is found."

No matter how many more trailing digits the user adds to the end
of a number after the decimal point, the whole number part is going
to determine which member of the union is the best match because of
the range restriction.

For the string "99991.0000000000000123456789", the first matching union
member will still be:

      type decimal64 {
        fraction-digits 13;

Also, the more I think about it, the more I like the idea of adding the
enumeration to the end of the union.  For a string containing any
positive number larger than 99999999999999999.9 or containing any
negative number larger than -99999999999999999.9, the first matching
union member would be the enumeration.

Here, then, is the revised proposal:

  typedef real {
    type union {
      type decimal64 {
        fraction-digits 18;
        description
          "Positive numbers larger than 99999999999999999.9
           SHALL be represented as an overflow.

           Negative numbers larger than -99999999999999999.9
           SHALL be represented as an underflow.";
      }
    }
  }

Regards,

David Spakes

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 May 2009 17:18:25 -0700

> over "hack", thank you very much.

I don't think Juergen's concern was the name of the data type.

Two usual questions that come up for any standards proposal:

  1) what problem is being solved?

  2) are there any existing standards which could be used instead?

I am not convinced either question has been answered yet.
It sure looks like we have a need for fixed-point,
not for real (or floating point) numbers, and if we did,
there is the IEEE 754 spec that a NETCONF needs to implement
already for XPath 1.0 support.

> union member would be the enumeration.

Think a bit more.
IMO, this 'nan' sort of enum hides real errors.
Do you really want to set the leaf to 'overflow'
and return <ok> for the edit-config request,
or just reject the request with an 'invalid-value' error?

Unless 'overflow' is a normal, usable value for that leaf
then is should not be saved in the configuration.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 May 2009 05:54:54 +0200

> over "hack", thank you very much.

Sorry my rather pointed statement. But let me explain myself:

If I understand the XSD decimal correctly, then the XSD decimal
actually does what you want and only if you use the fractionDigit
constraining facet (which is optional), the XSD decimal becomes a
fixed point decimal. (Note that this also explains why the canonical
format supresses trailing zeros.)

What we have currently in YANG is a fixed point decimal (since
fraction-digits is mandatory) plus a proposed union to turn a
collection of fixed point decimal types back into what XSD considers a
decimal. Compared to XSD, I do think this design is somewhat backwards
and I prefer the XSD approach.

My proposal: Make fraction-digits an optional type restriction in YANG
and we align to XSD and do not need the union typedef anymore.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 May 2009 21:21:16 -0700

> and we align to XSD and do not need the union typedef anymore.

We already discussed the optional vs. mandatory fraction-digits
field.  If the data modeler does not want any fraction-digits,
then int64 should be used instead of decimal64.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 May 2009 06:36:29 +0200

> then int64 should be used instead of decimal64.

I can subscribe to the last sentence but it does not address what we
are talking about here, namely David's proposal to have a "floating"
decimal point.

Please check how the XSD types work. An XSD decimal without
fraction-digits is _not_ the same as an int; an XSD decimal without
fraction-digits is what I believe David's union tries to achieve.

The fraction-digits constraining facet in XSD fixes the number of
decimals after the decimal point, without this constraining facet, you
have a decimal without a fixed position of the decimal point and I
think this is what David wanted to achieve. To me, the XSD design
makes a lot of sense.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 May 2009 02:04:07 -0700

> think this is what David wanted to achieve. To me, the XSD design

XSD decimal is a string type -- an arbitrary length string
representing a number with a decimal point.

Why is a new data type needed?
There are lots of data types in XSD that are
not in YANG, so why is this one important?

Why can't the data modeler just choose between int64 and decimal64?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 May 2009 12:39:20 +0200

> representing a number with a decimal point.

Lets get rid of all types! Wonderful argument.

/js

---

From: David Spakes <[email-masked]>
Date: Fri, 15 May 2009 09:58:38 -0400 (EDT)

> then is should not be saved in the configuration.

I didn't mean to suggest that it would be valid to use one of the
enumeration values in an <edit-config>.  The enumerations would only
be used to represent an out-of-range state in the device; i.e.,

  typedef real {
    type union {
      type decimal64 {
        fraction-digits 18;
        range "-0.999999999999999999 .. 0.999999999999999999";
      }
      /* ... */
      type decimal64 {
        fraction-digits 1;
        range "-99999999999999999.9 .. 99999999999999999.9";
      }
      type enumeration {   // not valid for configuration
        enum overflow;
        enum underflow;
      }
    }
    description
      "Positive numbers larger than 99999999999999999.9
       in state data SHALL be represented as an overflow.

       Negative numbers larger than -99999999999999999.9
       in state data SHALL be represented as an underflow.";
  }

> and we align to XSD and do not need the union typedef anymore.

I agree with Juergen that making the fraction-digits substatement
optional for decimal64 would accomplish the same thing as the typedef
union, and I would be in favor of that change.

Regards,

David Spakes

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 May 2009 07:18:18 -0700

> Lets get rid of all types! Wonderful argument.

Nobody is suggesting any lame strawman.

I am asking why we need both int64 AND decimal64 with optional
decimal point. Isn't a decimal64 with 0 decimal places the
same as int64?  Why is this overlap needed?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 15 May 2009 16:36:39 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> field.

I agree with Andy.  Making fraction-digits optional seems to me as a
nice-to-have (at best).  I don't think this is important enough to
make this change now.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 May 2009 07:47:00 -0700

> nice-to-have (at best).  I don't think this is important enough to

I prefer to keep the built-in types as simple as possible
and let users create more sophisticated data types with
the typedef-stmt.

IMO, overlap in the built-in types leads to confusion.

Andy

---

From: David Spakes <[email-masked]>
Date: Fri, 15 May 2009 10:49:57 -0400 (EDT)

> same as int64?  Why is this overlap needed?

How do you represent "52.3" or "99991.000001" with floating precision
as an int64 and tell where the decimal point goes?

> union, and I would be in favor of that change.

I have one additional thought about Juergen's proposal.

A secondary goal of the typedef was to apply a range on each decimal64 in
the union so the possible values begin and end on a base-10 boundary.
The range for each value of fraction-digits in the union is different but
all share one common property: the number of digits is always the same (if
you exclude the leading zero for fraction-digits 18).  The same goal could
be accomplished with Juergen's proposal if we added that decimal64 type
could be restricted with the "length" statement.  Section 9.3.3 would need
to be changed with new text like this:

9.3.3.  Restrictions

   A decmial64 type can be restricted with the "range" statement
   (Section 9.2.4).

   A decmial64 type can be restricted with the "length" statement
   (Section 9.4.4) to limit the number of valid digits.  If specified,
   the length limitation applies neither to the sign nor to the
   leading zero for values between -1 and 1 (not inclusive).

Regards,

David Spakes

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 May 2009 07:57:10 -0700

> as an int64 and tell where the decimal point goes?

IEEE 754 (float64)

Why do we need floating precision in NETCONF?

If we really need it, then let's add float64 back to
the built-in types.  I do not think it is needed.

Andy

---

From: David Spakes <[email-masked]>
Date: Fri, 15 May 2009 11:37:38 -0400 (EDT)

> the built-in types.  I do not think it is needed.

I am of the opinion that some users will need to represent ratios,
but in the real world few if any applications will ever need the full
power of IEEE 754 floats.

A decimal64 with fraction-digits 1 can represent numbers as large as
99,999,999,999,999,999.9 (ninty-nine quadrillion).  That's astronomically
large.  What real world application would need a number larger than this?

A decimal64 with fraction-digits 18 can represent numbers as small as
0.000000000000000001 (10^-18).  That's infinitesimally small.  What real
world application would need something more precise than this?

If this group were to decide to reintroduce float64, I'd go along with
that decision, but personally I think it's overkill.

Regards,

David Spakes

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 May 2009 09:05:58 -0700

> world application would need something more precise than this?

A data modeler will choose the fraction-digits value
that is best-suited for their intended use.
Choosing 1 or 18 depends on the semantics.
The most common value seems to be 2.

> that decision, but personally I think it's overkill.

I was not suggesting that.
I was pointing out that the WG already had float64
and replaced it with decimal64.  I still do not
see (except for your calculator MIB) why a NETCONF agent
needs floating precision numbers.  I think the survey
Phil did showed that fixed-point numbers are needed in NM,
not floating-point.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 16 May 2009 13:47:49 +0200

> and let users create more sophisticated data types with

The problem is that we do not agree what "simple" means. To me, the
proposed "real" union was an indication that we might have got the
built-in types not simple enough.

A decimal64 represented internally by an int64_t value plus the
information about the number of fraction decimals seems to be what
Dave wanted to achieve with his union. A decimal64 with the
fraction-digits statement essentially fixes the fraction part at data
model design time - so you can optimize your internal storage to just
the int64_t value. For me, all this seems clean and pretty simple.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 16 May 2009 06:38:04 -0700

> the int64_t value. For me, all this seems clean and pretty simple.

Here's the litmus test:

   - If you can build the desired data type out of
     existing built-in types, then there is no need
     for a new built-in type.  Just use typedef instead.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 16 May 2009 06:49:57 -0700

> the int64_t value. For me, all this seems clean and pretty simple.

It seems like reinventing the IEEE 754 standard to me.
If I want a 64-bit number that represents a floating-point
number, then I am going to use this existing standard.
There is plenty of existing free code to support it,
and no need to reinvent it.

Storing floating-point in an int64 is not a valid problem statement.
Storing FP in 64 bits of space *is* a valid problem statement.
If there is a need for this data type, then a standard
already exists.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 16 May 2009 16:20:06 +0200

>      for a new built-in type.  Just use typedef instead.

So you propose to remove several of the existing builtin types?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 16 May 2009 16:28:00 +0200

> and no need to reinvent it.

A decimal is not an IEEE 754 float. If people want to bring back
floats, then they should indeed use IEEE 754 floats. Having a decimal
type which requires a fraction-digits statement that people then put
into a big union in order to achieve a decimal without a
fraction-digits statement just smells so badly.

> Storing FP in 64 bits of space *is* a valid problem statement.

For me, none of these two are a problem statements.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 16 May 2009 08:33:36 -0700

> So you propose to remove several of the existing builtin types?

My preference would be to remove the 8 and 16 bit numeric types
and put them in the yang types draft, but it is not a big deal.
The extra types can save memory, if the developer cares about that.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 16 May 2009 08:38:14 -0700

> For me, none of these two are a problem statements.

Please provide the problem statement then.
It is really unclear why the standard needs to
bother with this at all.  Put the union typedef
in your YANG module if you want that derived data type.

Andy

---

From: David Reid <[email-masked]>
Date: Sat, 16 May 2009 16:16:02 -0400

> The extra types can save memory, if the developer cares about that.

I agree with Andy about moving the 8 and 16 bit types to the yang types draft.

-David Reid

---

From: David Spakes <[email-masked]>
Date: Mon, 18 May 2009 09:41:12 -0400 (EDT)

>      for a new built-in type.  Just use typedef instead.

In general, I agree with this line of thinking.  That's why my proposal
was to add the typedef for "real" to draft-ietf-netmod-yang-types-03.txt.

However, I also believe in simplicity.  Why make it necessary to define a
typedef at all when a tiny change of semantic on the base type elegantly
does the same thing?  If fraction-digits were made an optional
substatement for decimal64 as Juergen suggested, then anyone needing a
decimal-point-moves-around type could have it, and anyone needing a
fixed-position-decimal-point type could have it.

Regards,

David Spakes

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 May 2009 16:09:47 +0200 (CEST)

Hi,

David Spakes <[email-masked]> wrote:
> decimal-point-moves-around type could have it

We can probably add many simple types.  The question is if we see a
use case for them.  I don't think a floating point calculator is
representative.  You mentioned "ratios" as a use case, could you
elaborate a bit?  What kind of ratios did you have in mind that could
not be modeled with the current decimal64 type?

/martin

---

From: David Spakes <[email-masked]>
Date: Tue, 19 May 2009 10:56:17 -0400 (EDT)

Martin,

I didn't have anything specific in mind when I talked about the ratios.
My tenacity comes from my first years at SNMP Research when I worked the
technical support desk (early 1990s).  I remember fielding more than a
few calls from customers who wanted to encode floating point numbers in
SNMP messages but don't recall the specifics.

If the group decision is not in favor of Juergen's proposal to make the
fraction-digits substatement optional, I would still like to see the
typedef of union find a place in draft-ietf-netmod-yang-types-03.txt as
originally proposed.

Regards,

David Spakes