[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Floating point usage in a MIB module
Hi
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.
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.
Sharon
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Thursday, January 29, 2004 6:04 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]; Mreview (E-mail)
Subject: RE: Floating point usage in a MIB module
Well.... we should realize (accept?) that the base protocol exchanges
Bandwith for these links also in IEEE floating point format. So we could
decide that we rather see it as an integer, but the underlying
instrumentation seems to be floating point.
So ...
Thanks,
Bert
> -----Original Message-----
> From: Sharon Chisholm [mailto:schishol@nortelnetworks.com]
> Sent: donderdag 29 januari 2004 18:08
> To: Mreview (E-mail)
> Subject: RE: Floating point usage in a MIB module
>
>
> Hi
>
> I think the first question is do we want to encourage floating point
> numbers? I think historically we have tended to go with selecting the
> correct units to prevent floating points. As in using bits per micro
> seconds as appose to seconds.
>
> Sharon
>
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Thursday, January 29, 2004 11:45 AM
> To: Mreview (E-mail)
> Subject: Floating point usage in a MIB module
>
>
> MIB Doctors, do we believe that this is a proper
> way to express a 32-bit floating point number?
>
> TeLinkBandwidth ::= TEXTUAL-CONVENTION
> DISPLAY-HINT "d"
> STATUS current
> DESCRIPTION
> "This type is used to represent link bandwidth in bps. This
> value is represented using a 32 bit IEEE floating point
> format."
> REFERENCE
> "IEEE Standard for Binary Floating-Point Arithmetic,
> Standard 754-1985"
> SYNTAX Unsigned32
>
> I think that at least the DISPLAY-HINT seems weird here, no?
> Now, the author
> may have done so because of a warning he got if there was no
> display hint.
>
> But is Unsigned32 the best way? Or would an OCTET STRING
> SIZE(4) be better
> with a DISPLAY HINT of "1d.3d" or something like that. I
> don't think we have
> a way to properly provide a DISPLAY-HINT for a float, do we?
>
> Thanks,
> Bert
>
>