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?

  • 4
    $\begingroup$ Compute $90\cdot \pi/180$ using floating point types. You don't get exactly $\pi/2$. $\endgroup$ Oct 22, 2013 at 20:37
  • 2
    $\begingroup$ 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 $\endgroup$
    – imranfat
    Oct 22, 2013 at 20:37

4 Answers 4


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

  • 4
    $\begingroup$ ah more a tecnical answer! :D $\endgroup$
    – Gizmo
    Oct 22, 2013 at 20:42
  • 8
    $\begingroup$ @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$. $\endgroup$ Oct 23, 2013 at 10:19
  • 10
    $\begingroup$ @deed02392 More probably than the architecture, it's the implementation of $\tan$. $\endgroup$ Oct 23, 2013 at 10:40
  • 5
    $\begingroup$ The reciprocal of cosine is secant, not tangent. Of course, for angles very close to $\frac{\pi}{2}$, the difference is negligible. $\endgroup$
    – Dan
    Oct 24, 2013 at 5:19
  • 4
    $\begingroup$ It's funny that the number is now 1.63312394e+16, did some Google employee see your answer and observe their search engine answer was off? :) $\endgroup$
    – Gizmo
    Apr 25, 2017 at 8:12

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.

  • $\begingroup$ 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$ $\endgroup$ Oct 24, 2013 at 11:09
  • $\begingroup$ I tried this in node.js, and it works! > ((1.0 - 0.9) - 0.1) >> -2.7755575615628914e-17 $\endgroup$ Dec 3, 2013 at 15:47
  • $\begingroup$ 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. $\endgroup$
    – Darien
    Dec 3, 2013 at 21:17
  • $\begingroup$ @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. $\endgroup$
    – Darien
    Dec 13, 2013 at 22:04
  • $\begingroup$ 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. $\endgroup$
    – AlexR
    Nov 6, 2014 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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .