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

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

Solution 2:

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.

Solution 3:

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