To compute a constant of calculus (2019)

[clangcmp]

Disappointing, did not see the extremely easy and quite efficient method of calculating e through continued fractions.

  S =[2,1,2] 
  T =0

  for P in range(200):
    S += [1,1,(4 + 2*P)]

  for x in range(len(S)-1):
    T = 1 / (T + S[-(x+1)])

  print(S[0] + T) # value of e

[raiph]

There are many ways to compute e. :)

(The article's original title -- "To compute a constant of calculus: A treatise on multiple ways" -- described its purpose better than the truncated one submitted here on HN. I see posters suggesting various solutions. Perhaps someone will create a public repo based on the article and then folk can add solutions.)

> did not see the extremely easy and quite efficient method of calculating e through continued fractions.

(That could be misinterpreted by readers of this thread who have not read the OP. The OP includes several continued fractions, including ones that seem simpler to me than the one you've shown, though that might be because I'm no expert.)

I'm curious what name is normally given to the fraction you showed? And are you saying it is more efficient than the Brother series?

[thaumasiotes]

You made me curious. It's easy to see that the Maclaurin series converges quickly by the nature of the terms.

Since e ≈ 2.7 1828 1828 459, it is very close to the rational number 271,801/99,990 = 2.7(1828) . A continued fraction expansion should pick up on that approximation quite quickly, which will make the expansion look efficient. Will the continued fraction continue converging as quickly if you keep going after you reach that particular rational approximation?

[miguelmurca]

Super cool article. Brownie points for the callback at the end to "To Compute a Constant of Calculus: (A treatise on multiple ways)" :^)

[codesections]

The code in this post is in Raku[0] — pretty much the perfect language for expressing something in "multiple ways". There's More Than One Way To Do It, as we like to say.

[0]: https://docs.raku.org

[bjornsing]

I just skimmed through, but I didn’t see the method I expected to find: Use the Taylor series for f(x) = e^x around f(0) to compute e = f(1). Should be pretty efficient and straightforward, right?

[phkahler]

>> but I didn’t see the method I expected to find: Use the Taylor series for f(x) = e^x around f(0) to compute e = f(1)

Is that the one where e = 1 + 1/1! + 1/2! + 1/3! + ... ?

Steve Wozniak used that method to compute several thousand digits of e on an Apple II back in the day. I think Byte ran an article on it.

Super easy because each term is just the previous term divided by N.

[raiph]

It's included (he calls it Newton's), and he follows it with the even better Brother's.

[not2b]

Yes, the Taylor series converges very quickly, but for some reason the author insists on only using the problem that originally introduced Bernoulli and Euler to the number e.

[clangcmp]

They did. They called it Newton's series

[self_buddliea]

Reading this reminds me of Leibniz's formula for pi:

Although it computes the value correctly, it is almost completely useless on a computer. All the elements of the series are reciprocals of odd numbers, hence you will get errors on every term.

[raiph]

Are you saying that because (typically) arbitrary precision rationals are too slow, and floating point yields errors, or for some other reason?

(Raku supports arbitrary precision rationals, and they're normalized to minimize the denominator size, and remain pretty performant until the denominator exceeds 64 bits, so I'm thinking they might do OK for correctly computing transcendentals to maybe 15 decimal digits or so.)