Subject: RE: Double

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 21 Feb 2001 11:28:59 -0500

For the stats listed as "64 bit integer", that is what we need, a 
64 bit integer.  To fix it correctly, we change the word "double" in
"type" to something else (UINT64 I believe).

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 10:48 AM
> To: Rosen, Brian
> Cc: [email-masked]'
> Subject: Re: Double
> 
> 
> "Rosen, Brian" wrote:
> > 
> > A number of statistics parameters are defined as type 
> double, and possible
> > values are listed as any 64 bit integer.  This is 
> inconsistent, doubles
> > are double precision floating point.  
> 
> Yes, that's the common definition and the current usage is confusing,
> but technically the spec. can define it as whatever it wants.
> 
> 
> > The best solution is to change the
> > type to UINT64, 
> 
> Do you mean change the type *name*?
> 
> > but given the current text, you have to assume double
> > precision
> > floating point 
> 
> Why?
> 
> > (and of course you can't actually get a 64 bit integer in
> > a double precision fp).
> 
> 
> First let's decide what we need, 64 bit integers, double precision 
> floating point, or both.  Then let's decide what to call it/them.
> 
> -troy
>

---

From: Eric Cheung <[email-masked]>
Date: Fri, 23 Feb 2001 07:35:02 -0500

Currently "double" is defined as "8 byte signed integer" in 12.1.2 of
the RFC.  This will make it INT64 if we change the wording.

I realize that the current values in statistics (Duration, Octets Sent,
Octets Received, Packets Sent, Packets Received) are always >=0. 
However, do we need the extra range offered by UINT64 vs INT64?

My consideration is that in Java there is no native 64-bit unsigned
integer type.  There is BigInteger class, but is a bit of a hassle to
use.   Sticking to INT64 will be a lot more convenient for Java
implementations.

Eric