2

I'm trying to use a calculator to verify the following formula $$ e=\lim_{n\to\infty} (1 + (1/n))^n. $$

According to the calculator the value of $e$ to 9 decimal place accuracy is $2.718281828$.

When I plug in $n=1000000000$ above, I get that $1.000000001^{1000000000}\approx 2.718281827$, which is pretty close to $e$.

However, when I plug in $n=10000000000$ I get that $1.0000000001^{10000000000}\approx 2.718942354$, which is further from $e$, despite having plugged a higher natural number for $n$. Then, when I plug in much higher natural numbers for $n$, it seems be getting closer to $1$. What might I doing wrong?

Aaron Hendrickson
  • 6,042
coffeefeet
  • 29
  • 4
    BTW, $$\left(1+\frac1n\right)^{n+\frac12}$$ has better convergence, but it will also suffer from rounding errors when $n$ is too large. – PM 2Ring Jun 16 '21 at 20:29
  • 3
    There's good info here about how computers handle floating-point arithmetic: https://stackoverflow.com/q/588004/4014959 However, calculators don't always do stuff in the same way that computers do it. – PM 2Ring Jun 16 '21 at 20:33
  • @PM2Ring Why $1\over 2$? Is there a different number you could put there to get "better convergence?" (I'm curious) – Mike Pierce Jun 16 '21 at 21:08
  • 1
    @Mike Well, for $n>0$, we get $(1+\frac1n)^n < e < (1+\frac1n)^{n+1}$, and both of those expressions converge to $e$ as $n$ grows. So $n+\frac12$ is a natural choice. BTW, this is related to the (real) solutions of $x^y=y^x$, see here & the links therein for more details. For small $n$, there are certainly better choices than $n+\frac12$. – PM 2Ring Jun 16 '21 at 21:48
  • A powerful computational engine such as Wolfram Alpha actually gets things write when $n=1000000000$. See here. – Joe Jun 16 '21 at 21:49
  • (cont) For actual computation, it's better to rearrange it to $(1+1/(n-1/2))^n$, and make $n$ a power of 2, so you can do the exponentiation by repeated squaring. – PM 2Ring Jun 16 '21 at 21:51
  • Here's a little Sage / Python script that shows the results of $(1+1/m)^{m+k}$ for $k$ in $(0, 1/2, 1)$. And this script shows we can do better than $k=1/2$. – PM 2Ring Jun 16 '21 at 22:15
  • BTW, if the goal is to compute decimal digits of $e$, there are better ways, especially if you want lots of digits. Eg, https://math.stackexchange.com/a/1295561/207316 – PM 2Ring Jun 16 '21 at 22:19

2 Answers2

10

I assume this is just calculator rounding errors. For some sufficiently high $n$, your calculator won't want to think about the number $$1.00000000000000000000000000000000000...0000000000000000000000000001$$ but will instead just round that to $1$. For your example with $n = 10\,000\,000\,000$, it looks like the calculator is still pretty happy with that number, but somewhere in the calculation of $\left(1+{1 \over n}\right)^n$ it becomes unhappy and makes rounding errors. Specifically what errors depends on how your calculator handles calculating powers of floats (decimal numbers).

Mike Pierce
  • 18,938
  • 1
    I have given in my answer what happens precisely not with a pocket calculator but with a numerical analysis software, Matlab. – Jean Marie Jun 16 '21 at 22:10
4

I would like to give here the behavior of a numerical analysis software, Matlab, to which we have asked to compute $\left(1+\frac{1}{10^n}\right)^{10^n}$ for $n=1,2,\cdots 20$:

$$\begin{array}{|r|r|} \hline 1& 2.000000000000000\\ 2& 2.593742460100002\\ 3& 2.704813829421529\\ 4& 2.716923932235594\\ 5& 2.718145926824926\\ 6& 2.718268237192298\\ 7& 2.718280469095753\\ 8& 2.718281694132082\\ 9& 2.718281798347358\\ 10& 2.718282052011560\\ 11& 2.718282053234788\\ 12& 2.718282053357110\\ 13& 2.718523496037238\\ 14& 2.716110034086901\\ 15& 2.716110034087023\\ 16& 3.035035206549262\\ 17& 1.000000000000000\\ 18& 1.000000000000000\\ 19& 1.000000000000000\\ 20& 1.000000000000000\\ \hline \end{array}$$

Why this sudden change past $10^n=10^{16}$ ?

Because, with $\left(1+10^{-17}\right)^{10^{17}}$, we are below the machine's epsilon ( a classical expression) which is precisely

$$eps=2.220446049250313 \times 10^{-16}$$

and is defined as the smallest "floating point" number representable with Matlab.

In fact $\left(1+10^{-17}\right)^{N}$ is like $\left(1+0\right)^{N}=1$ for this software.

The fact that the results are never very good (never better than a $3 \times 10^{-8}$ approximation: recall that $e \approx 2.718281828459046...$) is another thing and should deserve a separate analysis.

Remark: for another interesting occurence of the machine's epsilon, see here.

Jean Marie
  • 81,803