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

Question

I typed in $\tan 90^{\circ}$ in Google and it gave $1.6331779\mathrm{E}16$. How did it come to this answer? Limits? Some magic?

Answer 1

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}$.

Answer 2

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

Answer 3

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.

Answer 4

Because it seems that Google Calculator works internally

• in radians instead of degrees
• with floating-point arithmetic instead of symbolic computation

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.