(1+(1/n))^nの極限でeの値を求める

大きくなる原因をより詳しく言うと

2進数で表現すると n=10^p に対する 1+1/n の値は正確に表現できず, 常に 0.5 ulp 程度の誤差は考えられる. IEEE754 の倍精度実数であれば 2^-53 程度. つまり, もとから (1+1/n)^n の真の値を計算しているわけじゃなくて (1+1/n+ε)^n の計算をしている (手元計算機における ε は絶対値でだいたい 10^-16 くらい).
この ε の存在は n が小さいときには ((1+1/n)^n の値が e から離れているので) 無視できるが, n が大きくなると無視できなくなる. で, n=10^9 のときに破綻した, と.
実際, n を 2 のべきにすると p=52 まできちんと計算していくはずです.

　NO3です。

　大きくなる原因は、(1+(1/n)の部分が四捨五入で真の値よりも大きくなるからでしょう。

> (1+(1/n))^nを計算機に入力し、nの値をだんだん大きくしていくと(1+(1/n))^nがeより大きくなってしまいます。

Google電卓や、表計算ソフトの関数等で試したところ、
質問者さんの計算結果と同じものが出てきました。
ちなみにnをもっと大きくすると、そのうちeの真の値より小さくなります。

元々この極限の計算は、振動しながらeに近づくのかもしれないと考えました
(eより大きくなったり小さくなったりを繰り返してeに収束する場合です)。
そこでとりあえずf(x) = (1+(1/x))^xとおいて、
f(x)の増減を調べてみました。
結果、f(x)は単調増加の関数だと分かりました。
なのでnを増やし続ければ、(1+(1/n))^nは増え続けながらeに収束するはずです。

ANo.3の方が仰る通り、計算の際の誤差が原因だと思います。
普通にやっていると、コンピューターは小数1.1の真の値さえも扱えません
(コンピューターでは二進数で数を扱いますが、
十進数1.1は、有限の二進数では表現不可能です。
また、コンピューターで扱える桁数には限りがあります)。
そのような誤差が累積していった結果なのかもしれません。

残念ながら、計算結果が真の値より増加してしまうような誤差が
どこで発生しているのかは分かりません。
べき乗の計算アルゴリズムあたりが怪しい気もしますが…。

　有効桁数の関係でしょう。

　そのような計算をするのでしたら、ｎに見合っただけの桁数を考慮しなければなりません。
　ｎをもっと大きくしたら桁落ちで(1+(1/n)の部分が１になり、答えは１になると予想しています。

n = 10^9 のときに 1 + 1/n は正確な値になっていますか?

これだけでは説明のしようがありません. なぜなら, どのような結果が得られたのか分からないので解釈のしようがありませんし, あなたがどのような操作を行ったのかもわからないので再現もできないからです.

まず, あなたが行った操作を明らかにしてください. 「計算機に入力し」とはどのようなことを意味するのですか? プログラムを作ったのだとしたら, どのようなプログラムなのかを示してください.
そして, いかなる n に対してどのような値が得られたのかを書いてください.