Subject: Re: [netmod] Y59: float64 and float32 typedefs

From: Randy Presuhn <[email-masked]>
Date: Mon, 29 Dec 2014 17:50:20 -0800 (GMT-08:00)

Hi -

>From: David Spakes <[email-masked]>
>Sent: Dec 29, 2014 2:03 PM
>To: Randy Presuhn <[email-masked]>
>Cc: [email-masked], David Spakes <[email-masked]>
>Subject: Re: [netmod] Y59: float64 and float32 typedefs
...
>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?

There is another implication which comes into play when values
can be set via other management interfaces or computed within
an implementation: if an implementation's internal representation
is, for example, IEEE 754 64-bit float, there will be a set of
possible IEEE 754 values which would not survive the round trip
through the string representation.

The big caveat for implementors to consider with a type like this
is that they cannot rely on their floating point hardware (or
emulation package) to produce values (as results of arithmetic
operations) that will be within the set of string values supported
by this type definition, so if they're using the IEEE types internally,
they'd need to wrap logic that updates netconf-accessible values with
"de-fuzzing" logic.  I think typical floating point epsilon logic
for equality comparisons probably wouldn't work correctly in all cases,
but someone needs to do the math to see what happens on the corner cases.

Randy