41–50 of 86 posts
But if I enter 100k, it takes 30 seconds to get to reporting 10k digits worth of progress.
Hmm. Have to think about that one. Just cause it's asking JS to do comparisons of much larger numbers?
> this simple one still converges at about 0.6 decimal digits per term. Quick proof of this: as the number of terms n in the sum goes to infinity, the ratio of each term to the previous one is approximately 1/4 - the first factor contributes m/(m+1) , the second q/(q+2) for some m and q that go to infinity along with n , the third contributes 1/4. If we counted base 4, then the value of each digit would be on average…
His demo page, in my Chrome, if I enter 10000, it takes about 2 seconds to finish with 10k digits. But if I enter 100k, it takes 30 seconds to get to reporting 10k digits worth of progress. Hmm. Have to think about that one. Just cause it's asking JS to do comparisons of much larger numbers?
On any standard unix system with bc installed - it's preinstalled on most of them, you can calculate pi to $n digits using bc: bc -l <<< "scale=$n; 4*a(1)"
The algorithm seems to be at least quadratic in the length. On a 2014 i7 Mac mini, (n, time(sec)) = (1000, 0.29), (2000, 1.65), (4000, 9.70), (8000, 58.42).
His demo page, in my Chrome, if I enter 10000, it takes about 2 seconds to finish with 10k digits. But if I enter 100k, it takes 30 seconds to get to reporting 10k digits worth of progress. Hmm. Have to think about that one. Just cause it's asking JS to do comparisons of much larger numbers?
I'd bet a good portion of the difference is between rendering the additional digits as it goes.
His demo page, in my Chrome, if I enter 10000, it takes about 2 seconds to finish with 10k digits. But if I enter 100k, it takes 30 seconds to get to reporting 10k digits worth of progress. Hmm. Have to think about that one. Just cause it's asking JS to do comparisons of much larger numbers?
His demo page, in my Chrome, if I enter 10000, it takes about 2 seconds to finish with 10k digits. But if I enter 100k, it takes 30 seconds to get to reporting 10k digits worth of progress. Hmm. Have to think about that one. Just cause it's asking JS to do comparisons of much larger numbers?
His demo page, in my Chrome, if I enter 10000, it takes about 2 seconds to finish with 10k digits. But if I enter 100k, it takes 30 seconds to get to reporting 10k digits worth of progress. Hmm. Have to think about that one. Just cause it's asking JS to do comparisons of much larger numbers?
On any standard unix system with bc installed - it's preinstalled on most of them, you can calculate pi to $n digits using bc: bc -l <<< "scale=$n; 4*a(1)"
Earlier quoted context omitted.
I'd bet a good portion of the difference is between rendering the additional digits as it goes.
What do you mean, doesn't it do that either way?
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