Subject: Double

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 20 Feb 2001 18:49:43 -0500

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.  The best solution is to change the
type to UINT64, but given the current text, you have to assume double
precision
floating point (and of course you can't actually get a 64 bit integer in
a double precision fp).

Brian

---

From: Chuong Nguyen <[email-masked]>
Date: Wed, 21 Feb 2001 08:40:47 -0600

I rather see that the change to UINT64 than floating point.
Because if we keep the double, then do we have to change the
"Possible Values:" description to
"a 32 bit whole number and a 32 bit fraction" which will make the intended
data to
be smaller than what we orginally wanted - UINT64.

Chuong

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: Troy Cauble <[email-masked]>
Date: Wed, 21 Feb 2001 10:47:42 -0500

"Rosen, Brian" wrote:
> 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