[Inori]

I got bored in math class, so I figured out how to generate e using the following formulae:


Edit: I forgot a factorial in these and mathJax sucks, so I'm not editing them.

This can also be explained more simply as:


The problem with this is that e, like phi and pi, is both transcendental and irrational, meaning it's impossible to get its exact value (which would be infinite decimal places). Also like pi and phi, e is commonly expressed with a concise 2.718. This isn't going to do it for me, because I love pushing systems to their limits (ha). As such, I made the below script for the purpose of (with enough memory and a good cpu) breaking the world record for most decimal places of e calculated.

Code:

"""
Script to calculate e to a ridiculous number of digits

Pipe output to a file for full represented value via:
    python e.py>e.txt
"""

from math import factorial,ceil,floor
from sys import stdout,stderr
from time import strftime
from decimal import *

def fib(n):
    a,b,c=1,1,0

    for r in bin(n)[3:]:
        calc=b*b
        a,b,c=a*a+calc,(a+c)*b,c*c+calc

        if r=='1': a,b,c=a+b,a,b

    return b

def e(prec):
    res=[Decimal(1.0)]
    getcontext().prec=prec+fib(int(ceil(ceil((prec/2)/1.618/2)+prec/1.618)))-int(floor(prec/2))
    stderr.write("digits: "+str(getcontext().prec-1)+"\n")

    for i in range(prec+1,0,-1):
        res.extend([Decimal(1.0)/Decimal(factorial(i))])
    return sum(res)

# set rounding option to the most accurate (essentially just cut off the end and don't round)
getcontext().rounding=ROUND_HALF_UP
# write current time to stderr, which doesn't pipe to a file via stdout
stderr.write(strftime("%H:%M:%S\n"))
# write result to stdout
print(e(48))
# write time after operation to stderr
stderr.write(strftime("%H:%M:%S\n"))

Spoiler: Programming explanation (read if you plan on running this)

99% of the time, I use Python 2 (which still works for this script), but here I chose to use Python 3 because of the integrated cdecimal library, as opposed to 2's pure python decimal library, which speeds things up by ridiculous amounts.

By using the included method call, e(48), I can generate ~39.1 million decimal places in 15 seconds, which is a decent chunk of disk space but pathetic compared to the current record (1,400,000,000,000 decimal places). So, if anyone has a super beefy computer with Python 3, would you mind running this with something like e(128), piping the output to a text file, and seeing what happens?

[Rick]

Aren't your first two expressions wrong?

The first is undefined (It's infinite). And the second is just 1...

Obviously the infinite sequence you defined below is correct, and you 100% didn't come up with it yourself, but the expressions don't describe it.

[insidious]

Aren't your first two expressions wrong?

The first is undefined (It's infinite). And the second is just 1...

Obviously the infinite sequence you defined below is correct, and you 100% didn't come up with it yourself, but the expressions don't describe it.

In addition to digging up a post from a month ago, I'm not sure you understand the logic that is going into this code. It's a recursive function. That's why it's 1. and the first one won't go on for infinity...

[Rick]

In addition to digging up a post from a month ago, I'm not sure you understand the logic that is going into this code. It's a recursive function. That's why it's 1. and the first one won't go on for infinity...

The second one is a limit, the limit of the expression you described is 1 as the second term (1/n) approaches 0 as n approaches infinity.

Secondly 1 + 'The sum of the reciprocal of all natural numbers' is infinite, and that's very well established. Did you mean (1/i!) instead of (1/i)?

I'm talking about the expressions not the code.

[Inori]

In addition to digging up a post from a month ago, I'm not sure you understand the logic that is going into this code. It's a recursive function. That's why it's 1. and the first one won't go on for infinity...

The second one is a limit, the limit of the expression you described is 1 as the second term (1/n) approaches 0 as n approaches infinity.

Secondly 1 + 'The sum of the reciprocal of all natural numbers' is infinite, and that's very well established. Did you mean (1/i!) instead of (1/i)?

I'm talking about the expressions not the code.

Sorry for the confusion, it is supposed to be n! and i!. Don't know how that got by me

[insidious]

The second one is a limit, the limit of the expression you described is 1 as the second term (1/n) approaches 0 as n approaches infinity.

Secondly 1 + 'The sum of the reciprocal of all natural numbers' is infinite, and that's very well established. Did you mean (1/i!) instead of (1/i)?

I'm talking about the expressions not the code.

Ah I wasn't certain what you meant,

Sorry for the confusion, it is supposed to be n! and i!. Don't know how that got by me

Thanks for clearing that up

[Rick]

Sorry for the confusion, it is supposed to be n! and i!. Don't know how that got by me

They're still wrong then, the first gives e+1 because 0! = 1, and the second is still 1 because as x approaches inf (1/x!) also approaches 0.

[Inori]

They're still wrong then, the first gives e+1 because 0! = 1, and the second is still 1 because as x approaches inf (1/x!) also approaches 0.

Regarding the first one, programmatic and mathematical operations of this algorithm give different results. If that's incorrect mathematically, think of it as pseudocode. With the second, it's summation, not a product. If it approaches 0, it's simply adding a value approaching 0 to the sum. How does that make the result incorrect?

[Rick]

Regarding the first one, programmatic and mathematical operations of this algorithm give different results. If that's incorrect mathematically, think of it as pseudocode. With the second, it's summation, not a product. If it approaches 0, it's simply adding a value approaching 0 to the sum. How does that make the result incorrect?

If you're not going to stick to the conventional rules that come along with limits and summinations, then don't use them? Just write out the series as you did below and don't even try to use proper notation if "it's just psudocode", what's even the point if you're writing out an expression. The sigma notation is the limit of summation in itself, you don't need to write it out twice. If you want to do the limit of a series then just google it, because you wrote out the limit of an expression. Obviously the second one isn't a product, it's the limit of an expression as x approaches infinity.

tl;dr Don't try to look smart by writing expressions that you don't understand or don't bother to check, just stick to stuff you understand.

[Inori]

If you're not going to stick to the conventional rules that come along with limits and summinations, then don't use them? Just write out the series as you did below and don't even try to use proper notation if "it's just psudocode", what's even the point if you're writing out an expression. The sigma notation is the limit of summation in itself, you don't need to write it out twice. If you want to do the limit of a series then just google it, because you wrote out the limit of an expression. Obviously the second one isn't a product, it's the limit of an expression as x approaches infinity.

tl;dr Don't try to look smart by writing expressions that you don't understand or don't bother to check, just stick to stuff you understand.

I mean, I'm in 10th grade math and trying to learn some stuff on my own time, but by all means rip me to shreds