[Purdue-pm] Computing Euler's Number (Perl Weekly Challenge 21)

[Mark Senn]

>> Write a script to calculate the value of e, also known as Euler’s number
>> and Napier’s constant.
>
>Which is 1 + ( 1 / $n ) )**$n , where $n approaches infinity.
>
>It is easy to put that in a subroutine compute_euler ( $n ), and then
>increment $n until you blow off the top of Perl 5's integer.
>
>I think the closest you could get without getting into Math::BigFloat would
>be 2.71828182845904 , and I'm not seeing clear enough documentation to
>really work on it. I suspect that $x = Math::BigFloat->new( 1 + ( 1 / $n )
>)**$n ) wouldn't work as intended, not because of problems with
>Math::Float, but because Perl 5 can't handle the equation within the new()
>well enough to give a Math::BigFloat result.
>
>Meanwhile, another site says:
>
>> But it is known to over 1 trillion digits of accuracy!
>
>So, when is it "done"? When we get to billions of digits? The 50 digits
>listed on the wiki page? compute_euler( 2 ** 53 ) to get the largest int
>Perl can handle without BigInt?
>
>I think this question is underspecified. Thoughts? Suggestions?
>-- 
>Dave Jacoby

In TeX notation
e = \sum_{n=0}^\infty {1\over n!} = 1/1 + 1/1 + 1/(1*2) + 1/(1*2*3) + ...
according to
https://en.wikipedia.org/wiki/E_(mathematical_constant)

(I'll be doing this in Pel 6 using sums of fractions where each fraction
and the sum are FatRats (Fat Rationals).  From
https://docs.perl6.org/type/FatRat:
    A FatRat is a rational number stored
    with arbitrary size numerator and denominator. Arithmetic operations
    involving a FatRat and optionally Int or Rat objects return a FatRat,
    avoiding loss of precision.
Perl 6 has "sequences" built in that make dealing with mathematical
series easier and more elegant.

Like pi, e is never "done"..."it just keeps going and going".  The very loose
specification in Perl Weekly Challenge 21:
    Write a script to calculate the value of e,
    also known as Euler’s number and Napier’s constant.
doesn't spec how many significant digits.  So I just make up something
I'm interested in computing and documenting that.

The lack of tight specifications for the problems make it impossible to
automatically compare solutions objectively.  On the other hand, I think
that's fine---I'm more interested in seeing the different ways people
choose to solve the problems instead of how numerically precise the
solutions are.  Damian Conway's answers are almost always the best in my
opinion.

-mark