# Why does the google calculator give $\tan 90^{\circ} = 1.6331779e^{+16}$?

I typed in $\tan 90^{\circ}$ degrees in google and it gave $1.6331779e^{+16}$. How did it come to this answer? Limits? Some magic?

• Compute $90\cdot \pi/180$ using floating point types. You don't get exactly $\pi/2$. – Daniel Fischer Oct 22 '13 at 20:37
• It is an incredibly big number. I think it is some internal rounding issue so it gives such a big number, rather than an error message. Have you tried the same question with radians? Just curious – imranfat Oct 22 '13 at 20:37

The closest IEEE-754 double value to $\pi/2$ is $1.5707963267948965579989817342720925807952880859375$. The cosine of that, on standard x86_64 hardware evaluates to $6.123233995736766 \times 10^{-17}$. The reciprocal of that is $1.633123935319537 \times 10^{16}$.

• ah more a tecnical answer! :D – Gizmo Oct 22 '13 at 20:42
• @wok No, dividing by zero will get you an infinity, if the numerator isn't zero, and a NaN if it is zero, in IEEE floating point. What we have here is that a value ($\pi/2$) is approximated by the closest representable value. Then - depending on the implementation - the cosine of that approximation is computed as accurately as possible [or very close to as accurately as possible, a relative error of $2^{-50}$ would be about the end of tolerance], which results in a value of about the same magnitude ($\approx2^{-52}$) and opposite sign as the used approximation to $\pi/2$. – Daniel Fischer Oct 23 '13 at 10:19
• Interesting how it's still not quite the same answer. I wonder what this tells us about the architecture they use. – deed02392 Oct 23 '13 at 10:36
• @deed02392 More probably than the architecture, it's the implementation of $\tan$. – Daniel Fischer Oct 23 '13 at 10:40
• The reciprocal of cosine is secant, not tangent. Of course, for angles very close to $\frac{\pi}{2}$, the difference is negligible. – Dan Oct 24 '13 at 5:19

As Daniel Fischer said, it's because of rounding errors within IEEE floating-point math, which is extremely widespread in computers and programming languages. Since he's explained why it's precisely that number, I'll take a stab at the more general answer.

# The example

((1.0 - 0.9) - 0.1) = -2.7755575615628914*10^-17


This is obviously mathematically wrong, but it occurs because the computer (A) does not have infinite precision and (B) does not store numbers in base-10. The key that 0.9 and 0.1 cannot be cannot be exactly represented, just like how "one third" cannot be exactly represented in decimal.

The problem doesn't show immediately (print(0.9) comes out fine) because the computer is smart enough to round small deviations when it converts them to decimals, but the "relative distance" between 0 and -2.8*10^-17 is a bit too much to hide.

# Bits and bytes

Assuming we're looking at a 32-bit float, -0.9 is stored as:

Section         Bits                       Translation
+/1 sign bit    1                          Is negative
exponent:       01111110                   -1 (126 above a -127 offset)
mantissa        11001100110011001100110    0.79999995231628426710886


Notice how the mantissa contains a repeating 1100? pattern? It's almost exactly like storing 1/3 as 0.3333333333 in decimal. In both cases you can't store it precisely without running out of space.

Anyway, when you put the parts of that representation together, you get:

(-1) * 2^(-1) * (1+ 0.79999995231628426710886)


Or roughly -0.8999999761581421. This disconnect between the decimal representation (which is nice) and the binary representation (which is ugly... er, incomplete) is the first domino in a potential cascade of subtle rounding error.

• IMO, the binary representation in your example is actually quite pretty: it's a truncation of $0.8 = 8/10 = 12/15 = 1100_2/1111_2 = 0.110011001100\dots_2$ – Ilmari Karonen Oct 24 '13 at 11:09
• I tried this in node.js, and it works! > ((1.0 - 0.9) - 0.1) >> -2.7755575615628914e-17 – Erel Segal-Halevi Dec 3 '13 at 15:47
• Yes, Javascript actually has only has double numbers, even when you write integers, which makes it easy to demonstrate the problem with JSFiddle and similar tools. Note: As long as your integers are within +/- 2^53 they can still be exactly represented. This is because a 64-bit double has 53 bits for the sign and mantissa. – Darien Dec 3 '13 at 21:17
• @IlmariKaronen : Good point, this is analogous to the problem of expressing 1/3 in decimal, where you are forced to approximate it as 0.33333 etc. In this case, the repeating-ness occurs in binary storage. – Darien Dec 13 '13 at 22:04
• On my machine the error shows up from 1-0.7-0.3 = 5.55111e-17 and evaluates "correctly" for 1-0.6-0.4 and 1-0.5-0.5. – AlexR Nov 6 '14 at 20:45

This is apparently the consequnce of some rounding error. The number given would be the correct result for $\tan(89.9999999999999964917593431035141398\ldots^\circ)$.

Because it seems that Google Calculator works internally

The use of radians means that GC is using an angle of $\frac{\pi}{2}$ radians. The nearest representable double value is $1.5707963267948965579989817342720925807952880859375$. I shall denote this approximated value by $\frac{\pi}{2} - \epsilon$, where $\epsilon \approx 6.123233995736766 \times 10^{-17}$ (calculated by using a higher-precision value of $\pi$).

Recall that $\tan (\frac{\pi}{2} - \epsilon) = \cot \epsilon = \frac{1}{\tan \epsilon}$. On my machine, this evaluates to $1.633123935319537 \times 10^{16}$. (The small-angle approximation of $\cot \epsilon \approx \frac{1}{\epsilon}$ happens to give the same answer.) This is close to what Google Calculator returned, but differs by 33 ppm.