Hacker News new | past | comments | ask | show | jobs | submit login
Multiple ways to compute e in Raku (perl.org)
126 points by gbacon 27 days ago | hide | past | web | favorite | 38 comments



This article is a love letter to both mathematics and programming. It is awesome to read something and grasp the joy and playfulness of the author. The maths are explained in a simple way. The programming concepts go from the straightforward to the delightfully weird (and let't not kid ourselves, Raku shines the most the weirder things get). And the final result is downright fun. I love it.


Damian is a magician in the way how he teaches different subjects. His talk on calculating PI was fun too.


This looks surprisingly neat, honestly. I've never used Perl, let alone Perl 6, but I think I see why people cared about it.


Perl is pretty great and it was THE language to know before Java took over the enterprise in the early-mid 2000s, and python later.

Perl is its own thing, definitely, and it does a lot of things extremely well (though not always extremely fast) using code that is as succinct as you want it to be, sometimes to a fault.

It is worth learning because of its utility and because of what it can teach, even though you probably won't use it a lot.

Perl 5 documentation still stands out to me as a perfect example of how official language documentation should be. Lots of examples, lots of explanation, standard library and third party modules are named extremely sanely, and it's all just documented so well. Even joke Perl5 modules are documented extremely well; it's just part of the culture that other languages seriously need to adopt.


Raku represents quite an advancement on Perl 5. Perl was a "kitchen sink" scripting language when it debuted, and Raku is a modern take on that, which means that it has lots of undiscovered corners still, places that will likely be major programming paradigms of tomorrow.


Is it officially appropriate to talk about Perl in the past tense?


Perl 5 will continue to be the official "Perl". Development on that continues, and it has an extensive community, though not nearly as large as Python, which was once its peer.

What was Perl 6 will, moving forward, be known as "Raku".


Is that a "yes it is"?


No, it isn't.


No, just about people caring about it. (Okay, that was flip, but Perl has really lost its niche, and not many people are very excited about it now.)


Nah, plenty of people still care about it (I should know, I'm one of them!). And with regular expressions front-and-center in perl, I still find it wonderful for text munging.


Maybe I'm just bitter because of Parrot. I so wanted to use it for my language.


Then you should maybe have a look at MoarVM (https://moarvm.org). It is now the main backend for Raku (née Perl 6) and is all that Parrot was intended to be, and then some. If you want to get into it, you might want to have a look at https://github.com/edumentab/rakudo-and-nqp-internals-course (course materials that implemented a Ruby and a PHP on MoarVM).


That looks extremely promising!


Is Parrot dead (Monty Python pun intended)? I've lost track of the different Perl 6 implementations and their subparts.


Yes, the Parrot project is in deep, very deep hibernation.


I wouldn't read too much into it. "X is dead" is such a common sentiment on HN it's somewhere between funny and tiresome.


No. Perl and Raku are different, albeit related, languages.


I think technically yes, because the present tense should be referring to Raku instead.


Raku is not the direct successor to Perl, active Perl development continues.


No, Perl still exists (in the form of Perl 5) and is used a lot and will continue to be developed, now unhampered by Raku (formerly known as Perl 6).


Computing e to thousands of decimal places is an interesting exercise for the mathematically inclined students in a beginning programming class. If you use the ∑1/n! series you can fairly easily do it even in a language that does not have built in arbitrary precision or an arbitrary precision library.

Let's say you want to deal with numbers to 1000 decimal places. Pick a base that is a power of 10, such as 10000. Represent a number as an array of 251 base 10000 digits, with the first item of the array being the integer part, and the remaining 250 being 250 base 10000 "decimal" digits.

You need two of these arrays. One represents 1/n!, and the other is the cumulative sum of the series so far.

You need two large precision operations. To go from 1/n! to 1/(n+1)! involves simply dividing by n+1. As long as we limit n+1 to under 10000, we only have to handle division with a single digit denominator. Limiting n thusly is not a problem--it's enough to actually support calculating e to over 35000 decimal places, so our modest goal of 1000 is no problem.

Implement the division exactly like you would do division by a single digit with pencil and paper. The only thing you have to worry about is dealing with carry. You can have intermediate values as large as the carry x the base + base - 1, and since carry can be as large as base - 1, this means you can have intermediate values as large as base^2 - 1. Just pick base (10000 in my example) so that base^2 - 1 doesn't overflow the basic integer type of the language you are using.

The other large precision operation you need is addition, to accumulate the result from the division into the sum. Same as with division--just write it using the same algorithm you would use with pencil and paper. Add digits right to left, with carry.

By using a base that is a power of 10, it is easy to figure out the base 10 representation of the final result for printing.


This also shows one of the things that Perl was great at in the past: Personalities. Despite "Just Another Perl Hacker" being a common meme, there were some people who just stood out. Wall, Schwartz, Christiansen, Conway.

I think this is important for a language and IMHO current Perl can't compete with that. For a while Ruby had a pretty colorful and productive batch, and of course Go has some elder statesmen of the industry.

JavaScript... Well, it certainly has a lot of coaches.


> Maksymilian Piskorowski found that if you happen to have a spare eight 9s, you can compute 𝑒 = (9/9 + 9^(-9^9))^(9^(9^9)), which is accurate to a little over 369 million decimal places.

Sure, because 9/9 = 1 and if you take x = 9^9^9, you get back (1 + x^(-1))^x, i.e. the first formula. It's cute, but I don't know if you could call it a "discovery".


You can see the formula Piskorowski used here [0], under "Best Approximations to e with n Copies of the Digit k". (All formulas marked with "MP").

He did in fact build up (1 + x^(-1))^x to slowly increase the accuracy of the formula.

[0] https://www2.stetson.edu/~efriedma/mathmagic/0804.html (The page may say 2004, but has been actively updated, and has references to 2019.)


Why does the Bernoulli formula take exponentially long in the exponent? Python’s native form (using either an integer or float exponent) and even an arbitrary percision computation to 1000 decimal digits using mpmath (also with either an integer or float exponent) are fast even for much larger exponents, and are accurate.

   >>> import math, timeit
   >>> x = 2**52
   >>> math.e
   2.718281828459045

   >>> (1+1/x)**x
   2.718281828459045
   >>> timeit.timeit(lambda: (1+1/x)**x, number = 10**6) / 10**6
   2.1324560802895575e-07
   >>> timeit.timeit(lambda: (1+1/x)**float(x), number = 10**6) / 10**6
   3.0082468304317444e-07

   >>> from mpmath import mp
   >>> mp.dps = 1000
   >>> (1+1/mp.mpf(x))**x
   mpf(‘2.7182818284590449335703801338125114…’)
   >>> timeit.timeit(lambda: (1+1/mp.mpf(x))**x, number = 10**3) / 10**3
   0.0004724335519131273
   >>> timeit.timeit(lambda: (1+1/mp.mpf(x))**mp.mpf(x), number = 10**3) / 10**3
   0.00047394841397181155
(Times in seconds.)


Also, Eccentric Euler’s one-liner:

  > '𝑒'.uniname
  MATHEMATICAL ITALIC SMALL E
  > say 𝑒
  2.718281828459045


How to compute e properly, with consideration for error bounds: https://www.nayuki.io/page/approximating-eulers-number-corre...


I can't connect to this page, as Firefox is automatically redirecting me to the HTTPS version of the page even though it's not supported. I guess I don't run into this that often given how common HTTPS is, but maybe someone else has this problem with this site? If you are, have you fixed it before? I've tried all of the methods mentioned on this[0] page, and I'm on Firefox 70 on Linux Mint.

[0]: https://stackoverflow.com/questions/30532471/firefox-redirec...


Are you sure it's Firefox doing that? I've got 70.0.1 on macOS and it's displaying fine (with the red crossed out padlock in the address bar).

You sure you don't have HTTPS-Everywhere or something similar running?

(There's noting in the response headers or html meta tags that look like it'd be redirecting you too https there...)


I am not convinced by the interest charging analogy. It is back to front. The yearly interest is by definition the total interest that would be paid given the already agreed charging period. The loan shark does not advertise a 100% yearly interest (on a single yearly payment) and then suddenly increase his winnings by cranking up the number of payments. It is then no more a 100% yearly loan.


I'd rather there was a single way to do something useful in Raku than multiple ways to do something completely useless.


It sounds like your goals for Raku are incompatible with the aims of the project, to the extent that making Raku into what you want would be "use something else" with extra steps.


So, what would you consider useful?


Raku = Perl 6, just in case you're wondering.


Sort of.

More like "Raku (nee Perl6)" I think.

It's (now) called Raku, because it isn't really Perl any more - even though it started out that way. "Perl" is Perl 5 now.


Spiritually, it is very much a kind of Perl, in a more concentrated form.


Oh sure. It used to be Perl. But it's "married out" now and taken a new name, and is off doing new things.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: