Mathematics Stack Exchange is a question and answer site for people studying math at any level and professionals in related fields. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|cite|improve this question
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
@DanielFischer:Commenting here since that is disabled where I meant to.Can you explain why a new tag should be deleted just because only 3 users opposed to that and many are not familiar with that?I did not check how many of my comments have been deleted but I tried to explain why I think it is necessary in one of those. But none of your favourite users cared to try and understand and mods are playing along with them! That is an existing topic different from the ones more frequently used and extensive research work is being done on that.Why should not the tag be introduced now ?Huh ? – user118494 3 hours ago
@user118494 Those were not just some arbitrary three users, but users who are rather knowledgeable in two pertinent topics, topology and tagging. If any one of those three users removes a tag from your question, you should stop and think before re-adding the tag. And if it's a new tag, make a meta thread explaining why you think having that tag would be beneficial, that's the place where arguments for and against a tag a) belong and b) can be better presented (and voted upon). If the meta thread comes out in favour of the tag, fine. If not, also fine, that tag shouldn't be then. – Daniel Fischer 3 hours ago
@DanielFischer :I hope they are not the only such knowledgeable ones.As a moderator of this site how about instead of blindly believing them,you look into that topic of i-convergence and judge the necessity of this tag for yourself.Hmm?I'm not going to make a meta-thread on this topic now since I know where that will lead to after seeing the rantings of these 3 "knowledgeable"s over a tag.They will do anything,other than understanding,in their power to get it disapproved and they already have YOU on their side. – user118494 2 hours ago
up vote 172 down vote accepted

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

share|cite|improve this answer
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.

share|cite|improve this answer
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)$.

share|cite|improve this answer

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.

share|cite|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.