You won't need Decimal to replace Java's BigInteger of course, as Python's integers are already big. Here I just redid your Mersenne Primes exercise using native Python ints, and also exposing the guts of a probable prime test that seems less flaky than the one you had to use (set at 50% reliable -- and changing its mind a lot, as there's randomness involved). The test I use is the Miller-Rabin test, with a citation to a certain page number in Knuth. Here's the output: runfile('/Users/mac/Documents/School_of_Tomorrow/mersennes.py', wdir='/Users/mac/Documents/School_of_Tomorrow') M1 = 2**2-1 = 3 M2 = 2**3-1 = 7 M3 = 2**5-1 = 31 M4 = 2**7-1 = 127 M5 = 2**13-1 = 8191 M6 = 2**17-1 = 131071 M7 = 2**19-1 = 524287 M8 = 2**31-1 = 2147483647 M9 = 2**61-1 = 2305843009213693951 M10 = 2**89-1 = 618970019642690137449562111 M11 = 2**107-1 = 162259276829213363391578010288127 M12 = 2**127-1 = 170141183460469231731687303715884105727 M13 = 2**521-1 = 6864797660130609714981900799081393217269435300143305409394463459185543183397656052122559640661454554977296311391480858037121987999716643812574028291115057151 M14 = 2**607-1 = 531137992816767098689588206552468627329593117727031923199444138200403559860852242739162502265229285668889329486246501015346579337652707239409519978766587351943831270835393219031728127 Here's the source code (which thanks calcpage and links to your video in the opening docstring): https://github.com/4dsolutions/School_of_Tomorrow/blob/master/mersennes.py As you'll see from lines 127 on, I do a brute force trial by division at first, to determine primehood, then switch to this more exotic algorithm going forward. It gets them all right. Once students develop an appetite for big integers, they're going to wonder about big reals (so called arbitrary precision). We can switch them to a full-blown math framework like Sage, but we don't have to, given these smaller libraries (decimal, gmpy2) are close at hand. Kirby On Sun, Feb 2, 2020 at 5:36 PM A. Jorge Garcia <calcpage@aol.com> wrote:
And here's BigInteger at work finding large Mersene Primes. https://youtu.be/-Snd7a55FrE
I'm gonna have to do the same in python with Decimal. What about the N() method in SAGE and numpy?
Regards, Al
Sent from BlueMail <http://www.bluemail.me/r?b=15774> On Feb 2, 2020, at 19:18, kirby urner <kirby.urner@gmail.com> wrote:
Hi Jorge --
I agree, it'd be interesting to apply a Riemann Sum algorithm using arbitrary precision as the number crunching type, versus IEEE754.
Freed from FORTRAN, you would have that option. I'll do it now...
[ sometime later ]
Here's a sandbox version: https://repl.it/@kurner/computepi
I'm comparing the convergent Rsum you give with one of Ramanujan's:
pi = 3.141591653589626571795976716612836217532486859692 start_time = 23183.62579051 end_time = 23205.729972367 elapsed time = 22.104181857001095 seconds
Ramanujan's converges really quickly, after 100 terms:
pi = 3.141592653589793238462643383279502884197169399375 start_time = 23205.731066136 end_time = 23205.838047055 elapsed time = 0.10698091900121653 seconds
That 2nd answer is correct as far as I'm showing it. One may tweak the repl to get even more precision.
I wonder how fast REPL.it is compared to my R-Pi. I'll be checking that later.
You're getting into clustering, cool!
That's a deep topic, with or without converging to Pi, wish I knew more.
Kirby
On Fri, Jan 31, 2020 at 8:30 PM < calcpage@aol.com> wrote:
Hi Kirby,
Love your post about arbitrary precision. I wish I had seen it before I started a project with my students computing PI on a Linux Cluster. Here's my blog post about our project so far if anyone is interested,
https://shadowfaxrant.blogspot.com/2019/12/cistheta-2019-2020-meeting-7-1215...
Regards, A. Jorge Garcia Teacher and Professor Applied Math, Physics and Computer Science http://shadowfaxrant.blogspot.com http://www.youtube.com/calcpage2009