Subject: Re: [netmod] Y59: what about decimal56 data type?

From: Randy Presuhn <[email-masked]>
Date: Mon, 29 Dec 2014 13:16:15 -0800 (GMT-08:00)

Hi -

These types have greater precision and smaller ranges
than their IEEE 754 floating-point counterparts.
That seems to me to be a bug-factory in the making.

Having greater precision than their IEEE 754 counterparts
means they'll have all the problems this group has
encountered in the handling of int64.

There's a quick summary at 
http://en.wikipedia.org/wiki/IEEE_floating_point

Randy

---

From: David Spakes <[email-masked]>
Date: Mon, 29 Dec 2014 17:03:32 -0500 (EST)

> http://en.wikipedia.org/wiki/IEEE_floating_point

Hi Randy,

On http://en.wikipedia.org/wiki/IEEE_floating_point, the section near
the bottom called "Character representation" says, "When using a decimal
floating point format the decimal representation will be preserved
using...16 decimal digits for decimal64...7 decimal digits for decimal32"

If I understand correctly, for my typedef to be fully compatible with
IEEE 754, we would need to reduce the number of digits in each range
substatement so that the combined total of magnitude and precision
would add up to 16 digits for float64 and 7 digits for float32.
Does everyone agree that I grasp the implication correctly?

Below, I have adjusted the typedefs based on my understanding of what
it would take to achieve complete compatibility with IEEE 754.  There
are fewer decimal64 members in each union (fewer values of fraction-digits
are represented).  Let's continue the discussion from this point.  Is this 
a step in the right direction?  Why or why not?

    typedef float64 {
      type union {
        type decimal64 {
          fraction-digits 16;
          range "-0.9999999999999999 .. 0.9999999999999999";
        }
        type decimal64 {
          fraction-digits 15;
          range "-9.999999999999999 .. 9.999999999999999";
        }
        type decimal64 {
          fraction-digits 14;
          range "-99.99999999999999 .. 99.99999999999999";
        }
        type decimal64 {
          fraction-digits 13;
          range "-999.9999999999999 .. 999.9999999999999";
        }
        type decimal64 {
          fraction-digits 12;
          range "-9999.999999999999 .. 9999.999999999999";
        }
        type decimal64 {
          fraction-digits 11;
          range "-99999.99999999999 .. 99999.99999999999";
        }
        type decimal64 {
          fraction-digits 10;
          range "-999999.9999999999 .. 999999.9999999999";
        }
        type decimal64 {
          fraction-digits 9;
          range "-9999999.999999999 .. 9999999.999999999";
        }
        type decimal64 {
          fraction-digits 8;
          range "-99999999.99999999 .. 99999999.99999999";
        }
        type decimal64 {
          fraction-digits 7;
          range "-999999999.9999999 .. 999999999.9999999";
        }
        type decimal64 {
          fraction-digits 6;
          range "-9999999999.999999 .. 9999999999.999999";
        }
        type decimal64 {
          fraction-digits 5;
          range "-99999999999.99999 .. 99999999999.99999";
        }
        type decimal64 {
          fraction-digits 4;
          range "-999999999999.9999 .. 999999999999.9999";
        }
        type decimal64 {
          fraction-digits 3;
          range "-9999999999999.999 .. 9999999999999.999";
        }
        type decimal64 {
          fraction-digits 2;
          range "-99999999999999.99 .. 99999999999999.99";
        }
        type decimal64 {
          fraction-digits 1;
          range "-999999999999999.9 .. 999999999999999.9";
        }
        type enumeration {
          enum overflow;
          enum underflow;
        }
      }
      description
        "The float64 type defines a large, finite set of real numbers with
         varying degrees of magnitude and precision.  An object of type
         float64 is able to express configuration and state data as any of
         the real numbers in the set.  The float64 type is suitable for
         applications that deal with ratios in which the decimal point is
         not fixed to a single position.

         The following restrictions ensure that the float64 type can be
         correctly implemented on all systems that support a
         double precision floating point types and comply with IEEE 754.

         Positive numbers larger than 999999999999999.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 -999999999999999.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 -999999999999999.9 and 999999999999999.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 float64 type through rounding or truncation.
         For example, pi could be rounded (down) to 3.141592653589793 or
         truncated to 3.141592653589793 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.";
    }

    typedef float32 {
      type union {
        type decimal64 {
          fraction-digits 7;
          range "-0.9999999 .. 0.9999999";
        }
        type decimal64 {
          fraction-digits 6;
          range "-9.999999 .. 9.999999";
        }
        type decimal64 {
          fraction-digits 5;
          range "-99.99999 .. 99.99999";
        }
        type decimal64 {
          fraction-digits 4;
          range "-999.9999 .. 999.9999";
        }
        type decimal64 {
          fraction-digits 3;
          range "-9999.999 .. 9999.999";
        }
        type decimal64 {
          fraction-digits 2;
          range "-99999.99 .. 99999.99";
        }
        type decimal64 {
          fraction-digits 1;
          range "-999999.9 .. 999999.9";
        }
        type enumeration {
          enum overflow;
          enum underflow;
        }
      }
      description
        "The float32 type defines a large, finite set of real numbers with
         varying degrees of magnitude and precision.  An object of type
         float32 is able to express configuration and state data as any of
         the real numbers in the set.  The float32 type is suitable for
         applications that deal with ratios in which the decimal point is
         not fixed to a single position.

         The following restrictions ensure that the float32 type can be
         correctly implemented on all systems that support a
         single precision floating point types and comply with IEEE 754.

         Positive numbers larger than 999999.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 -999999.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 -999999.9 and 999999.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 float32 type through rounding or truncation.
         For example, pi could be rounded (up) to 3.141593 or
         truncated to 3.141592 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

-------------------------------------------------------------
  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
-------------------------------------------------------------