Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RE: st: more than double precision (higher than 16 digit)

From (William Gould, StataCorp LP)
Subject   Re: RE: st: more than double precision (higher than 16 digit)
Date   Mon, 29 Nov 2010 11:27:49 -0600

Maarten Buis <> wrote, 

> Integers can be stored exactly, which is more precise then
> double, as long as the numbers remain between -2,147,483,647 
> and 2,147,483,620 if you store it as -long-. For numbers 
> larger than that there is no alternative to -double-.

This is a minor point, but I want to correct the part that reads, 
"Integers can be stored exactly, which is more precise that double".
What is true is that 

  Mathematical integers can usually be stored exactly.  Thus, 
  91 is exactly the number it appears to be regardless of whether 
  it is stored as a -byte-, -int-, long-, -float-. or -double-, 
  whereas 9.1, for example, is an approximatation to 9 + 1/10.
  9.1 stored as a -double -is a more accurate approximation 
  than it would be stored as a -float-.

  Concerning nonintegers, whereas 9.1 cannot be stored 
  precisely, 9.25 can.  The rule is that numbers with fractional parts
  that are powers of 2, or linear combinations of powers of 2, can be
  stored precisely as long as the range of the largest and smallest
  power of 2 required to represent the entire number is not too 
  big (24 for -float-, 53 for -double-).

  The largest integers that can be stored precisely in Stata are, 
       -byte-                       100
       -int-                     32,740
       -long-             1,147,483,620
       -float-               16,777,215   = 2^24 - 1
       -double-   9,007,199,254,740,991   = 2^53 - 1

  Thus, -double- can record larger integers than can -long-.
  Precise arithmetic can be preformed on these integers if
  no part of the calculation would produce a noninteger
  result outside the range +/- 9,007,199,254,640,991.

Thus, one should not hestiate to use -double-s to store integers.
If the ingegers are small, -long-, -int-, or -byte- can be used 
with no loss of precision and with the advantage of using less 

Concerning numbers used for identification (ID numbers), when assigned
by computer, they seldom exceed 4,294,967,295, that being the the
largest unsigned integer that can be expressed in 32 bits.  That, for
instance, is the current maximum used for an IP address.  New IP
addresses are, however, in short supply, and it is proposed to change
to a 48-bit encoding, allow a maximum of 281,474,976,710,65.  Note
that even that number is less than the largest integer that can be
stored in a Stata -double-.

With the advent of 64-bit computers, it is possible that
computer-assigned ID numbers could become as large as
18,446,744,073,709,551,615, which would exceed what can be stored as a
Stata -double-.  It is, however, worth noting that even in the case of
the Internet, the proposal is for 48-bit id numbers, not 64-bit.

Some human-generated ID numbers are larger than any of the maximums
stated above.  Think of Purchase Order Number
185-20101129-111749-4891, which might be written
185201011291117494891.  Those numbers, however, are usually designed
to be human readable.  The above number means department 185, issued
on 2010.11.29 at 11:17:49, order 4891.  Such numbers, in whatever 
style they are written, are best stored as as strings.  If you need 
to break into the ID number, you can usually extract the relevant pieces 
by taking substrings and converting those to numbers if need be.

I say usually, but I could say always without much fear of
contradiction.  That fact is that, until very recently, computers have
had no convenient way of precisely storing integers larger than
4,294,967,295, and even today, although integers as large as
18,446,744,073,709,551,615 are possible, for practical reasons the
upper limit is viewed as being 281,474,976,710,656, which as I said,
can be stored precisely as a -double-.

-- Bill
*   For searches and help try:

© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index