71–80 of 86 posts
The Chudnovsky brothers’ algorithm computes 14.18... digits per term. Its implementation in Scheme is only about a couple dozen lines of code. It computes a million pi digits in about 17.5 seconds on raspberry pi 4 in Gambit Scheme (57 seconds on the original raspberry pi, IIRC).
Earlier quoted context omitted.
That version already doesn’t work… once you fix the arrow function, there’s also the issue that most engines today don’t support proper tail calls, so nothing recursive will be portable. (But if it did, you could save a lot of characters by dropping unnecessary parentheses, expanding (i+1n)×4n to 4n×i+4n, replacing the const with a comma, removing semicolons…)
this is my perl golf version of the same series. You can probably can do something similar with js: map$l+=(-1) $_/(1-$_ 2) 4,1.. ;die$l
Earlier quoted context omitted.
I'd bet a good portion of the difference is between rendering the additional digits as it goes.
I didn't note timing numbers, but rendering digits in hex was basically instantaneous, even when doing a million (decimal) digits. Rendering the digits in decimal was significant delay (like 40 seconds for a million digits). That's why it just shows the hex until the very end, and it shows how long the decimal conversion takes.
Earlier quoted context omitted.
What do you mean, doesn't it do that either way?
Sure but one has 10x more digits than the other so takes a heck of a lot longer to convert and display the string for the same number of iterations. As a quick test of my theory the majority of the time is being spent trying to display the progress: - Default 100,000 = 58.276 - CSS display: none; = 22.359 - Display when done = 20.057
Hm, I was comparing the same number of digits displayed on screen though. One takes 2s to compute and display 10k digits of information on screen, one takes 30s to compute and display 10k digits of information on screen. same number of digits. At least according to the "progress" output that reads "Digits done".
I may be confused. But you have looked at the demo, right?
It will be much faster if you don't update the HEX values all the time (they are not that interesting anyway).
It is fun to scroll down and watch the "cutoff", where digits above that are not changing and digits below that are. That's just as fun in hex as it is in decimal. But yes, maybe I should add an option to turn that off.
Earlier quoted context omitted.
I didn't note timing numbers, but rendering digits in hex was basically instantaneous, even when doing a million (decimal) digits. Rendering the digits in decimal was significant delay (like 40 seconds for a million digits). That's why it just shows the hex until the very end, and it shows how long the decimal conversion takes.
You sure you don't mean converting digits to hex instead of rendering? The constant rendering of the hex digits as the work progresses results in a ~3x slowdown for 100k digits in my testing (see my other comment in this tree).
Doing a million digits in the console (with no status updates) took about an hour and doing it in that page took just over two hours.
Earlier quoted context omitted.
this is my perl golf version of the same series. You can probably can do something similar with js: map$l+=(-1) $_/(1-$_ 2) 4,1.. ;die$l
Doesn't work for me [0]. Perhaps HN messed it up somehow? [0]: https://tio.run/##K0gtyjH9/z83sUAlR9tWQ9dQUyVeX8NQVyXeSNNEx1...
Earlier quoted context omitted.
Apple seems to be the only browser developer that makes user-centric changes first, not developer-centric. I'm OK with that.
It seems user-centric to you know... make the browser work for what users what to use it for. Like generating digits of pi.
Earlier quoted context omitted.
It seems user-centric to you know... make the browser work for what users what to use it for. Like generating digits of pi.
Yes I'm sure there's a lot of consumers that want to calculate large amounts of digits of Pi in their browser..
But some users want to do it.