I wrote about precision right here and right here, however they had been fairly technical.

“Nice,” coworkers inside StataCorp stated to me, “however couldn’t you clarify these points in a method that doesn’t get misplaced within the particulars of how computer systems retailer binary and perhaps, simply perhaps, write about floats and doubles from a consumer’s perspective as a substitute of programmer’s perspective?”

“Mmmm,” I stated clearly.

Later, once I tried, I preferred the outcome. It incorporates new materials, too. What follows is what I now want I had written first. I’d would have nonetheless written the opposite two postings, however as technical appendices.

In Half 2 (forthcoming), I present the mathematical derivations underlying what follows. There are a number of attention-grabbing points underlying what follows.

Please excuse the manualish type of what follows, however I believe that what follows will finally work its method into Stata’s assist recordsdata or manuals, so I wrote it that method.

Syntax

Drawback:

. generate x = 1.1

. listing
  (Stata shows output displaying x is 1.1 in all observations)

. depend if x==1.1
     0

Resolution 1:

. depend if x==float(1.1)
   100

Resolution 2:

. generate double x = 1.1

. depend if x==1.1
  100

Resolution 3:

. set sort double

. generate x = 1.1

. depend if x==1.1
  100

Description

Stata works in binary. Stata shops knowledge in float precision by default. Stata preforms all calculations in double precision. Generally the mix leads to surprises till you suppose extra fastidiously about what occurred.

Remarks

Remarks are introduced underneath the headings

Abstract
Why depend==1.1 produces 0
How depend==float(1.1) solves the issue
How storing knowledge as double seems to unravel the issue (and does)
Float is loads correct to retailer most knowledge
Why don’t I’ve the issues utilizing Excel?

Abstract

Justifications for all statements made seem within the sections under. In abstract,

1. It generally seems that Stata is inaccurate. That isn’t true and, the truth is, the looks of inaccuracy occurs partly as a result of Stata is so correct.

2. You may cowl up this look of inaccuracy by storing all of your knowledge in double precision. This may double or extra the dimensions of your dataset, and so I don’t advocate the double-precision answer until your dataset is small relative to the quantity of reminiscence in your laptop. In that case, there’s nothing incorrect with storing all of your knowledge in double precision.

   The best option to implement the double-precision answer is by typing set sort double. After that, Stata will default to to creating all new variables as doubles, at the very least for the rest of the session. If all of your datasets are small relative to the quantity of reminiscence in your laptop, you possibly can set sort double, completely.

3. The double-precision answer is needlessly wasteful of reminiscence. It’s tough to think about knowledge which are correct to greater than float precision. No matter how your knowledge are saved, Stata does all calculations in double precision, and generally in quad precision.

4. The problem of 1.1 not being equal to 1.1 arises solely with “good” decimal numbers. You simply have to recollect to make use of Stata’s float() perform when coping with such numbers.

Why depend x==1.1 produces 0

Let’s hint by way of what occurs while you sort the instructions

. generate x = 1.1

. depend if x==1.1
     0

Right here is the way it works:

1. Some numbers don’t have any precise finite-digit binary illustration simply as some numbers don’t have any precise finite-digit decimal illustration. One-third, 0.3333… (base 10), is an instance of a quantity with no precise finite-digit decimal illustration. In base 12, one-third does have a precise finite-digit illustration, particularly 0.4 (base 12). In base 2 (binary), base 10 numbers comparable to 0.1, 0.2, 0.3, 0.4, 0.6, … don’t have any precise finite-digit illustration.

2. Computer systems retailer numbers with a finite variety of binary digits. In float precision, numbers have 24 binary digits. In double precision, they’ve 53 binary digits.

   The decimal number one.1 in binary is 1.000110011001… (base 2). The 1001 on the top repeats perpetually. Thus, 1.1 (base 10) is saved by a pc as

    1.00011001100110011001101
   

   in float, or as

    1.0001100110011001100110011001100110011001100110011010
   

   in double. There are 24 and 53 digits within the numbers above.

3. Typing generate x = 1.1 leads to 1.1 being interpreted because the longer binary quantity Stata performs all calculations in double precision. New variable x is created as a float by default. When the extra exact quantity is saved in x, it’s rounded to the shorter quantity.

4. Thus while you depend if x==1.1 the result’s 0 as a result of 1.1 is once more interpreted because the longer binary quantity and the longer quantity is in comparison with shorter quantity saved in x, and they don’t seem to be equal.

How depend x==float(1.1) solves the issue

One option to repair the issue is to vary depend if x==1.1 to learn depend if x==float(1.1):

. generate x = 1.1

. depend if x==float(1.1)
   100

Operate float() rounds outcomes to drift precision. While you sort float(1.1), the 1.1 is transformed to binary, double precision, particularly,

 1.0001100110011001100110011001100110011001100110011010 (base 2)

and float() then rounds that lengthy binary quantity to

 1.00011001100110011001101 (base 2)

or extra accurately, to

 1.0001100110011001100110000000000000000000000000000000 (base 2)

as a result of the quantity remains to be saved in double precision. Regardless, this new worth is the same as the worth saved in x, and so depend stories that 100 observations comprise float(1.1).

As an apart, while you typed generate x = 1.1, Stata acted as if you happen to typed generate x = float(1.1). Everytime you sort generate x = … and x is a float, Stata acts if if you happen to typed generate x = float(…).

How storing knowledge as double seems to unravel the issue (and does)

While you sort

. generate double x = 1.1

. depend if x==1.1
   100

it ought to be fairly apparent how the issue was solved. Stata shops

1.0001100110011001100110011001100110011001100110011010 (base 2)

in x, after which compares the saved outcome to

1.0001100110011001100110011001100110011001100110011010 (base 2)

and naturally they’re equal.

Within the Abstract above, I referred to this as a canopy up. It’s a cowl up as a result of 1.1 (base 10) shouldn’t be what’s saved in x. What’s saved in x is the binary quantity simply proven, and to be equal to 1.1 (base 10), the binary quantity must suffixed with 1001, after which one other 1001, after which one other, and so forth with out finish.

Stata tells you that x is the same as 1.1 as a result of Stata transformed the 1.1 in depend to the identical inexact binary illustration as Stata beforehand saved in x, and people two values are equal, however neither is the same as 1.1 (base 10). This results in an essential property of digital computer systems:

If storage and calculation are performed to the identical precision, it is going to seem to the consumer as if all numbers that the consumer varieties are saved with out error.

That’s, it seems to you as if there isn’t a inaccuracy in storing 1.1 in x when x is a double as a result of Stata performs calculations in double. And it’s equally true that it would seem to you as if there have been no accuracy points storing 1.1 when x is saved in float precision if Stata, observing that x is float, carried out calculations involving x in float. The very fact is that there are accuracy points in each instances.

“Wait,” you’re most likely considering. “I perceive your argument, however I’ve all the time heard that float is inaccurate and double is correct. I perceive out of your argument that it’s only a matter of diploma however, on this case, these two levels are on reverse sides of an essential line.”

“No,” I reply.

What you might have heard is true with respect to calculation. What you might have heard would possibly apply to knowledge storage too, however that’s unlikely. It seems that float offers loads of precision to retailer most actual measurements.

Float is loads correct to retailer most knowledge

The misperception that float precision is inaccurate comes from the true assertion that float precision shouldn’t be correct sufficient in the case of making calculations with saved values. Whether or not float precision is correct sufficient for storing values relies upon solely on the accuracy with which the values are measured.

Float precision offers 24 base-2 (binary) digits, and thus values saved in float precision have a most relative error error of plus-or-minus 2^(-24) = 5.96e-08, or lower than +/-1 half in 15 million.

1. The U.S. deficit in 2011 is projected to be $1.5 trillion. Saved as a float, the quantity has a (most) error of two^(-24) * 1.5e+12 = $89,407. That’s, if the true quantity is 1.5 trillion, the quantity recorded in float precision is assured to be someplace within the vary [(1.5e+12)-89,407, (1.5e+14)+89,407]. The projected U.S. deficit shouldn’t be recognized to an accuracy of +/-$89,407.

2. Individuals within the US work about 40 hours per week, or roughly 0.238 of the hours within the week. 2^(-24) * 0.238 = 1.419e-09 of every week, or 0.1 milliseconds. Time labored in every week shouldn’t be recognized to an accuracy of +/-0.1 milliseconds.

3. A most cancers survivor would possibly reside 350 days. 2^(-24) * 350 = .00002086, or 1.8 seconds. Time of loss of life is never recorded to an accuracy of +/-1.8 seconds. Time of prognosis isn’t recorded to such accuracy, nor may it’s.

4. The moon is claimed to be 384,401 kilometers from the Earth. 2^(-24) * 348,401 = 0.023 kilometers, or 23 meters. At its closest and farthest, the moon is 356,400 and 406,700 kilometers from Earth.

5. Most elementary constants of the universe are recognized to some components in 1,000,000, which is to say, lower than 1 half in 15 million, the accuracy float precision can present. An exception is the pace of sunshine, measured to be 299,793.458 kilometers per second. Report that as a float and you’ll be off by 0.01 km/s.

In all of the examples besides the final, quoted are worst-case situations. The precise errors rely upon the precise quantity and is a extra tedious calculation (not proven):

1. For the U.S. deficit, the precise error for 1.5 trillion is -$26,624, which is throughout the plus or minus $89,407 quoted.

2. For fraction of the week, at 0.238 the error is -0.04 milliseconds, which is throughout the +/-0.1 milliseconds quoted.

3. For most cancers survival time, at 350 days the precise error is 0, which is throughout the +/-1.8 seconds quoted.

4. For the space between the Earth and moon, the precise error is 0, which is inside throughout the +/-23 meters quoted.

The precise errors could also be attention-grabbing, however the most errors are extra helpful. Bear in mind the multiplier 2^(-24). All you must do is multiply a measurement by 2^(-24) and evaluate the outcome with the inherent error within the measurement. If 2^(-24) multiplied by the measurement is lower than the inherent error, you need to use float precision to retailer your knowledge. In any other case, it’s worthwhile to use double.

By the way in which, the method

maximum_error = 2^(-24) * x

is an approximation. The true method is

maximum_error = 2^(-24) * 2^(ground(log2(x)))

It may be readily confirmed that x ≥ 2^(ground(log2(x))) and thus the approximation method overstates the utmost error. The approximation method can overstate the utmost error by as a lot as an element of two. Float precision is satisfactory for many knowledge. There may be one form of knowledge, nonetheless, the place float precision will not be satisfactory, and that’s monetary knowledge comparable to gross sales knowledge, common ledgers, and the like. Individuals working with dollar-and-cent knowledge, or Euro-and-Eurocent knowledge, or Pound Stirling-and-penny knowledge, or some other forex knowledge, often discover it finest to make use of doubles. To keep away from rounding points, it’s preferable to retailer the info as pennies. Float precision binary can’t retailer 0.01, 0.02, and the like, precisely. Integer values, nonetheless, could be saved precisely, at the very least as much as sure 16,777,215.

Floats can retailer as much as 16,777,215 precisely. If saved your knowledge in pennies, that might correspond to $167,772.15.

Doubles can retailer as much as 9,007,199,254,740,991 precisely. If you happen to saved your knowledge in pennies, the would correspond to $90,071,992,547,409.91, or simply over $90 trillion.

Why don’t I’ve these issues utilizing Excel?

You do not need these issues while you use Excel as a result of Excel shops numeric values in double precision. As I defined in How float(1.1) solves the issue above,

If storage and calculation are performed to the identical precision, it is going to seem to the consumer as if all numbers that the consumer varieties are saved with out error.

You may undertake the Excel answer in Stata by typing

. set sort double, completely

You’ll double (or extra) the quantity of reminiscence Stata makes use of to retailer your knowledge, but when that’s not of concern to you, there aren’t any different disadvantages to adopting this answer. If you happen to undertake this answer and later want to change your thoughts, sort

. set sort float, completely

That’s all for at this time

If you happen to loved the above, it’s possible you’ll wish to see Half II (forthcoming). As I stated, There are a number of technical points underlying what’s written above which will curiosity these considering laptop science because it applies to statistical computing.