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

There are many well-known methods for efficiently numerically computing $\pi$, such as Chudnovsky's Method or perhaps Gauss-Legendre's algorithm. I was wondering what the best method for computing $e$ is.

I have used the Taylor's series expansion or $e^x$ at $x=1$, which is in fact very convergent and does not cost too much to compute:

$$e=\sum_{n=0}^{\infty}\frac{1}{n!} = 1+1+\frac{1}{2}+\frac{1}{6}+\cdots$$

Here are a table of some basic values:

n                    Estimation            Error (e - sum)
1                    1.0                   1.718281828459045
5                    2.708333333333333     0.009948495125712054
10                   2.7182815255731922    3.0288585284310443E-7
100                  2.7182818284590455    -4.440892098500626E-16

I am curious to know if there are even more efficient methods to compute $e$. Keep in mind that computational cost and convergence speed are the priorities.

share|cite|improve this question
See Finch's Mathematical Constants and – lhf Apr 12 '12 at 2:17
$e$ has a very simple continued fraction, and there are good bounds on the error made by stopping at the $n$th partial quotient. Another (possible) advantage is that all calculations can be carried out in exact rational arithmetic with no need for floating point. – Gerry Myerson Apr 12 '12 at 2:28
Your table is highly skewed by whatever errors appear inthe computation: a very basic use of the error term in the Taylor polynomial shows that for $n=100$ the approximation is better than $3/101!$, and this number is less than $10^{-159}$ (i.e. $159$ correct digits). Already $n=20$ gives you $20$ good digits, which is more than what your usual computer can handle – Martin Argerami Apr 12 '12 at 6:39
@Martin has hit the nail on the head. Your last error term is on the order of machine epsilon for double-precision floating-point. If you check the values between 10 and 100, you should find that the error stops decreasing because the successive terms are too small to be represented in the usual double data type. – Rahul Apr 12 '12 at 19:08
@m.k.: as you say, that's precisely when one uses appropriate software. The OP's table shows that he didn't use such a thing. – Martin Argerami Apr 12 '12 at 23:05
up vote 2 down vote accepted

A tiny C program from Xavier Gourdon to compute $9000$ decimal digits. (You may change that for more digits).

    int N=9009,n=N,a[9009],x;
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.