Finding e in R

Though I have loved math since childhood, I am not a mathematician. But I love studying math. And sometimes I find myself exploring numbers just for the fun of it, especially when I’ve been using RStudio or Octave for a project.

Finding Euler’s number e is not improbable nor terribly difficult. The number e is everywhere. There is more than one youtube video demonstrating the emergence of e using various techniques. Euler’s number is one of those really beautifully transcendent properties of mathematics that puzzles and mystifies. And I know of nothing closer to inherent truth in this world than the beauty of mathematics.

But I wasn’t thinking about e when I found it where I did. I was thinking about something else. I was pondering the relationship between an infinite series of integers and how they might relate to rational numbers. The question that occurred to me was simple — is there is limit to the following:

f(x) = \sum_{x=1}^{\infty} 1/x

Note that I wasn’t considering x = 0 because dividing by zero is not a good idea. And since I’m not using the values from the infinite series as an exponent, zero becomes problematic. So for the sake of cleanliness I stated the problem as listed above and wondered if a limit would emerge.

As a software developer, my approach to exploring the problem was naturally to write some code. The R code for this little project can be downloaded from github if you’re interested. As x gets larger, the fraction gets smaller. Clearly the higher the value we assign to x the return value will become increasingly smaller when compared to earlier iterations. But is there a limit?

As I played with the code, I realized that even though the function would always return increasingly smaller values as x grew larger, it would nevertheless continue to grow and grow, even as x approached infinity and  1/x approached zero.

But then my thoughts turned to the ever increasing number of fractions needed to get to the next highest integer value. For example, when x = 1 , the value returned from the function is 1. So to get the return value to the next highest full integer value, in this case 2, the function must add:

x = 1/1 + 1/2 + 1/3 + 1/4

Which returns the value 2.08333. For the next highest value, the function must add:

x = 1+1/2+1/3+1/4+1/5+1/6+1/7+1/8+1/9+1/10+1/11

Which yields 3.019877. And so on. The number of fractions required to get to the next highest whole integer value increases.

Okay. Then it dawned on me that there might be a pattern to the increase in the number of fractions. So I tried a few experiments. What I discovered is e emerges from a simple ratio created by the number of fractions required to attain the next highest integer value in the series.

So, for example, the total number of iterations required to attain is 4. The total number of iterations to attain is 11. Divide 11 by 4 and the result is 2.75. To attain the next highest integer part,, requires 31 iterations of the function. Take the current value for iterations and divide by the previous value, and the result is 2.818182. Continuing, to attain the next highest integer part,, requires 83 iterations of the function. Take the current value for iterations and divide by the previous value, and the result is 2.6774194.

If we continue, eventually the number of iterations of the functions at the current integer value divided by the number of iterations from the previous integer point appears to hover around e plus or minus a very very small fraction.

integer portion value of j prev j j / prevj value of i prev i i / previ i / j
2 3 1 3 4 1 4 1.333333333
3 7 3 2.333333333 11 4 2.75 1.571428571
4 20 7 2.857142857 31 11 2.818181818 1.55
5 52 20 2.6 83 31 2.677419355 1.596153846
6 144 52 2.769230769 227 83 2.734939759 1.576388889
7 389 144 2.701388889 616 227 2.713656388 1.583547558
8 1058 389 2.719794344 1674 616 2.717532468 1.582230624
9 2876 1058 2.718336484 4550 1674 2.718040621 1.582058414
10 7817 2876 2.718011127 12367 4550 2.718021978 1.582064731
11 21250 7817 2.718434182 33617 12367 2.718282526 1.581976471
12 57763 21250 2.718258824 91380 33617 2.718267543 1.581981545
13 157017 57763 2.71829718 248397 91380 2.718286277 1.5819752
14 426817 157017 2.718285281 675214 248397 2.718285648 1.581975413
15 1160207 426817 2.718277388 1835421 675214 2.718280427 1.581977182
16 3153770 1160207 2.718282169 4989191 1835421 2.718281528 1.581976809
17 8572836 3153770 2.718281929 13562027 4989191 2.718281782 1.581976723
18 23303385 8572836 2.718281908 36865412 13562027 2.718281862 1.581976696
19 63345169 23303385 2.718281872 100210581 36865412 2.718281868 1.581976693
20 172190019 63345169 2.718281784 272400600 100210581 2.718281815 1.581976711
21 468061001 172190019 2.718281836 740461601 272400600 2.718281828 1.581976707
22 1272321714 468061001 2.718281829 2012783315 740461601 2.718281829 1.581976707

One common method to derive e is:

e=lim_{x=0}^{\infty} (1 + 1/x)^{x}

But with the methodology I discovered using RStudio, no exponential function is required. It is a simple ratio. Using the initial approach I used while experimenting:

f(x) = \sum_{x=1}^{\infty} 1/x

And count the number of iterations of the function as the value of x increases. Round of the fractional part of the returned value, leaving only the whole integer part. When the integer part exceeds the previous integer part, divide the current count by the previous count and the result appears to get increasingly close to e.

The current iteration count (i) divided by the previous iteration count (previ) also holds true for the difference between i and previ as well. When the function tracks a difference value, j, which results from i – previ, and prevj = j – prevj, then that difference between iterations (j / prevj) also appears to hover around e after a number of iterations.

I created a github repo for the code here.

Another interesting thing which emerged is the consistent and somewhat puzzling number that emerges when we divide i by j or previ by prevj. The number that emerges appears to be close to 1.581977. I can’t find that number in any math literature, but it does appear to be interesting. If we use pi as the hypotenuse of a right triangle and e as one of the sides, the missing side would be 1.574976…which is close but not that close. I was hoping a simple relationship like that might emerge. But I don’t think it’s that simple.

The emergence of e from a simple ratio of iterations over a simple sequence of 1 divided by consecutive integers, however, does appear to be an actual phenomenon. While it is likely others have found this magic before me, I have not found the work. Then again, as I stated at the outset, I am not a mathematician. I just like math.

Posted in Big Data
One comment on “Finding e in R
  1. Daily alexa says:

    Сейчас в Big Data громадных технологических изменений не происходит, главное уже известно и доступно, и теперь вопрос в том, насколько индустрия в состоянии всё это обработать и принять на вооружение.

Leave a Reply

Your email address will not be published. Required fields are marked *