Re: Floating point usage in a MIB module

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Sharon Chisholm" <schishol@nortelnetworks.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Friday, January 30, 2004 5:05 AM
> Subject: RE: Floating point usage in a MIB module
...
> Well, if they are inevitable, then I would suggest that we write up a
> general TC as appose to one specific to bits per second with some comments
> that recommend that selecting the correct units to avoid using floating
> point is considered better practice.

Yup.  I think the case for float is most persuasive when the dynamic
range of the data exceeds 32- or 64-bit integer range.  Somewhat
less compelling is the case where the underlying hardware representation
is float, but with limited dynamic range.  In such a case, the only advantage
to using float is, ironically, avoiding float->integer conversion code in the
agent or for edges cases like NAN.

> To do the TC, an Octet String would seem like a better base type unless we
> fix the percision (first n bits before the . Next 32-n after). The two
> display methods would be  0.345 or 3.45 x 10-1 (or whatever that ends up
> being). The former is probably better.

I agree that Octet String makes more sense than an integer type.
I also think that we need to be very clear that fixed point and floating
point representations are suited to different tasks, and that to date
we've consistently addressed the fixed point case by choice of appropriate
scaling.

If we want to tackle both the floating point *and* the extended precision
problems, then I suggest that the OCTET STRING's SIZE should support
all of the IEEE floating point lengths in the TC, and that uses of the TC
could then limit precision if needed by limiting the choice of SIZEs.

Lots of good material is at http://grouper.ieee.org/groups/754/reading.html
including links to software implementations.

Randy