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 is not improbable nor terribly difficult. The number is everywhere. There is more than one youtube video demonstrating the emergence of 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 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:

Note that I wasn’t considering 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 gets larger, the fraction gets smaller. Clearly the higher the value we assign to 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 grew larger, it would nevertheless continue to grow and grow, even as approached infinity and 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 , 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:

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

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 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 2.xxx is 4. The total number of iterations to attain 3.xxx is 11. Divide 11 by 4 and the result is 2.75. To attain the next highest integer part, 4.xxx, 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, 5.xxx, 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 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 is:

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:

And count the number of iterations of the function as the value of 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 .

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 / prev*j) also appears to hover around 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 as the hypotenuse of a right triangle and 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 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.

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