arbitrary precision computing in K-12

A lot of our archived debates centered around how we might redesign (reform) the curriculum in light of computer languages, Python in particular. What I'm coming to lately is emphasizing arbitrary precision e.g. pi to literally a thousand places, as an especially attractive feature of computers in general. Mere calculators don't usually do arbitrary precision (I remember one Casio (?) with a scrolled display), but seem more reliable in giving the expected grade school results vs. answers we might get from using floating points (IEEE 754), which bring their own form of disillusionment. In other words, in going from a basic math topic, such as irrational numbers, to computers, why not emphasize the extrapolation of our algorithms to large numbers of decimal digits? Lets compute Phi as (1 + sqrt(5))/2 to hundreds of digits and check published sources (such multi-digit comparisons might mean converting to strings). We've done stuff like that around pi here on edu-sig, computing from algorithms (one of Ramanujan's in particular). These arbitrary precision numbers may not have much use in scientific and engineering applications (because nothing gets measured to that degree of precision) but I'm talking about bridging from math, so-called "pure math" in particular. My approach of late has been to use geometric objects (volumes, polyhedrons) and check that our computations may be exact to several hundred decimal points thanks to Python's Decimal. I also use the 3rd party gmpy2 library. Here's an essay on Medium if you'd like to read more: https://medium.com/@kirbyurner/calculator-of-tomorrow-using-arbitrary-precis... Kirby

More concretely, and continuing the arbitrary precision thread, one might think Python, with its clever duck typing, could take either floating point, or standard library Decimals, through precisely the same algorithm. That's so in some cases, but when we get to powering, one can't use the built-in pow( ) function with pow(Decimal, float), as a workaround for math.sqrt. sqrt(float) is fine of course, but you need Decimal.sqrt() whereas float.sqrt() is a syntax error. The algorithm has to "know in advance" what syntax to use, meaning we stray into type detection (what you'd think we might avoid, given numbers are numbers). I ended up with something kinda kludgey like this: def rt2(n): if "sqrt" in dir(n): return n.sqrt() else: return sqrt(n) A simple type check would be faster, by why not go all the way and let any object with a sqrt method use that instead of math.sqrt? Then I initialize my variables like this: if high: a = Decimal('1') seven = Decimal('7') five = Decimal('5') three = Decimal('3') else: a = 1 seven = 7 five = 5 three = 3 EF = a * rt2(seven - 3 * rt2(five)) EH = a * (3 - rt2(five))/2 EG = a * EF / 2 FH = a * (rt2(five) - 1)/2 HG = a * EG GF = a * rt2(three) * EG Corresponding pictures (if curious): https://mybizmo.blogspot.com/2020/01/quaker-curriculum-american-literature.h... That way I get my edge lengths as either floating point or decimal, depending on whether high (for "high precision") is set to True. Even then though, when I feed these six edges of a tetrahedron to the volume formula (six edges --> volume), I come up against needing a 2nd root and end up duplicating the rt2 definition inside the Tetrahedron class as _rt2. Details here: https://repl.it/@kurner/tetravolumes Mathematica (Wolfram Language) makes all this easier. But that's not a workaday coding language most people use. Given how most other computer languages work, I think introducing IEEE 754 floating points *in contrast with* an arbitrary precision type, is reassuring to students new to computers. Why not make the most of Decimal and/or 3rd party gmpy2? Show them they really *can* use pi or phi to a thousand places (you'd think computers would be able to do that). That's pedagogically important in my book. gmpy2 has native trig and allows complex numbers. Making floating points do all the work and calling those "real numbers" only adds to the pure math | engineering divide I'd like to see bridged. Using floating points only leaves the wrong impression that computers are actually bad at doing ordinary math textbook computations. Kirby

You've probably already considered SymPy or Sage (which is installable with conda now)? https://docs.sympy.org/1.5.1/modules/evalf.html :
N(sqrt(2)*pi, 5) 4.4429 N(sqrt(2)*pi, 50) 4.4428829381583662470158809900606936986146216893757
https://github.com/sympy/sympy/wiki/Dependencies :
gmpy (https://pypi.python.org/pypi/gmpy2). gmpy is a Python wrapper around the GNU Multiple Precision Arithmetic Library (GMP). If gmpy is installed, it may make certain operations in SymPy faster, because it will use gmpy as the ground type instead of the built-in Python ground types. If gmpy is not installed, it will fall back to the default Python ground types.
Currently a limited subset of the geometry module has been extended to
https://docs.sympy.org/1.5.1/modules/geometry/index.html#three-dimensions-an... : three dimensions, but it certainly would be a good addition to extend more. This would probably involve a fair amount of work since many of the algorithms used are specific to two dimensions. Sage has a bit more for 3D geometry http://doc.sagemath.org/html/en/reference/index.html#geometry-and-topology Sage also has bindings to gmpy / MPFR: http://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_mp... http://doc.sagemath.org/html/en/thematic_tutorials/index.html#geometry - http://doc.sagemath.org/html/en/thematic_tutorials/geometry.html#geometry - On Wed, Jan 29, 2020, 2:52 PM kirby urner <kirby.urner@gmail.com> wrote:
More concretely, and continuing the arbitrary precision thread, one might think Python, with its clever duck typing, could take either floating point, or standard library Decimals, through precisely the same algorithm.
That's so in some cases, but when we get to powering, one can't use the built-in pow( ) function with pow(Decimal, float), as a workaround for math.sqrt. sqrt(float) is fine of course, but you need Decimal.sqrt() whereas float.sqrt() is a syntax error. The algorithm has to "know in advance" what syntax to use, meaning we stray into type detection (what you'd think we might avoid, given numbers are numbers).
I ended up with something kinda kludgey like this:
def rt2(n): if "sqrt" in dir(n): return n.sqrt() else: return sqrt(n) A simple type check would be faster, by why not go all the way and let any object with a sqrt method use that instead of math.sqrt?
Then I initialize my variables like this:
if high: a = Decimal('1') seven = Decimal('7') five = Decimal('5') three = Decimal('3') else: a = 1 seven = 7 five = 5 three = 3
EF = a * rt2(seven - 3 * rt2(five)) EH = a * (3 - rt2(five))/2 EG = a * EF / 2 FH = a * (rt2(five) - 1)/2 HG = a * EG GF = a * rt2(three) * EG
Corresponding pictures (if curious):
https://mybizmo.blogspot.com/2020/01/quaker-curriculum-american-literature.h...
That way I get my edge lengths as either floating point or decimal, depending on whether high (for "high precision") is set to True.
Even then though, when I feed these six edges of a tetrahedron to the volume formula (six edges --> volume), I come up against needing a 2nd root and end up duplicating the rt2 definition inside the Tetrahedron class as _rt2. Details here:
https://repl.it/@kurner/tetravolumes
Mathematica (Wolfram Language) makes all this easier. But that's not a workaday coding language most people use.
Given how most other computer languages work, I think introducing IEEE 754 floating points *in contrast with* an arbitrary precision type, is reassuring to students new to computers. Why not make the most of Decimal and/or 3rd party gmpy2?
Show them they really *can* use pi or phi to a thousand places (you'd think computers would be able to do that). That's pedagogically important in my book. gmpy2 has native trig and allows complex numbers.
Making floating points do all the work and calling those "real numbers" only adds to the pure math | engineering divide I'd like to see bridged. Using floating points only leaves the wrong impression that computers are actually bad at doing ordinary math textbook computations.
Kirby _______________________________________________ Edu-sig mailing list -- edu-sig@python.org To unsubscribe send an email to edu-sig-leave@python.org https://mail.python.org/mailman3/lists/edu-sig.python.org/

There's a three.js renderer for 3D graphics in Sage: https://doc.sagemath.org/html/en/reference/plot3d/ On Wed, Jan 29, 2020, 5:21 PM Wes Turner <wes.turner@gmail.com> wrote:
You've probably already considered SymPy or Sage (which is installable with conda now)?
https://docs.sympy.org/1.5.1/modules/evalf.html :
N(sqrt(2)*pi, 5) 4.4429 N(sqrt(2)*pi, 50) 4.4428829381583662470158809900606936986146216893757
https://github.com/sympy/sympy/wiki/Dependencies :
gmpy (https://pypi.python.org/pypi/gmpy2). gmpy is a Python wrapper around the GNU Multiple Precision Arithmetic Library (GMP). If gmpy is installed, it may make certain operations in SymPy faster, because it will use gmpy as the ground type instead of the built-in Python ground types. If gmpy is not installed, it will fall back to the default Python ground types.
https://docs.sympy.org/1.5.1/modules/geometry/index.html#three-dimensions-an... :
Currently a limited subset of the geometry module has been extended to three dimensions, but it certainly would be a good addition to extend more. This would probably involve a fair amount of work since many of the algorithms used are specific to two dimensions.
Sage has a bit more for 3D geometry
http://doc.sagemath.org/html/en/reference/index.html#geometry-and-topology
Sage also has bindings to gmpy / MPFR:
http://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_mp...
http://doc.sagemath.org/html/en/thematic_tutorials/index.html#geometry - http://doc.sagemath.org/html/en/thematic_tutorials/geometry.html#geometry -
On Wed, Jan 29, 2020, 2:52 PM kirby urner <kirby.urner@gmail.com> wrote:
More concretely, and continuing the arbitrary precision thread, one might think Python, with its clever duck typing, could take either floating point, or standard library Decimals, through precisely the same algorithm.
That's so in some cases, but when we get to powering, one can't use the built-in pow( ) function with pow(Decimal, float), as a workaround for math.sqrt. sqrt(float) is fine of course, but you need Decimal.sqrt() whereas float.sqrt() is a syntax error. The algorithm has to "know in advance" what syntax to use, meaning we stray into type detection (what you'd think we might avoid, given numbers are numbers).
I ended up with something kinda kludgey like this:
def rt2(n): if "sqrt" in dir(n): return n.sqrt() else: return sqrt(n) A simple type check would be faster, by why not go all the way and let any object with a sqrt method use that instead of math.sqrt?
Then I initialize my variables like this:
if high: a = Decimal('1') seven = Decimal('7') five = Decimal('5') three = Decimal('3') else: a = 1 seven = 7 five = 5 three = 3
EF = a * rt2(seven - 3 * rt2(five)) EH = a * (3 - rt2(five))/2 EG = a * EF / 2 FH = a * (rt2(five) - 1)/2 HG = a * EG GF = a * rt2(three) * EG
Corresponding pictures (if curious):
https://mybizmo.blogspot.com/2020/01/quaker-curriculum-american-literature.h...
That way I get my edge lengths as either floating point or decimal, depending on whether high (for "high precision") is set to True.
Even then though, when I feed these six edges of a tetrahedron to the volume formula (six edges --> volume), I come up against needing a 2nd root and end up duplicating the rt2 definition inside the Tetrahedron class as _rt2. Details here:
https://repl.it/@kurner/tetravolumes
Mathematica (Wolfram Language) makes all this easier. But that's not a workaday coding language most people use.
Given how most other computer languages work, I think introducing IEEE 754 floating points *in contrast with* an arbitrary precision type, is reassuring to students new to computers. Why not make the most of Decimal and/or 3rd party gmpy2?
Show them they really *can* use pi or phi to a thousand places (you'd think computers would be able to do that). That's pedagogically important in my book. gmpy2 has native trig and allows complex numbers.
Making floating points do all the work and calling those "real numbers" only adds to the pure math | engineering divide I'd like to see bridged. Using floating points only leaves the wrong impression that computers are actually bad at doing ordinary math textbook computations.
Kirby _______________________________________________ Edu-sig mailing list -- edu-sig@python.org To unsubscribe send an email to edu-sig-leave@python.org https://mail.python.org/mailman3/lists/edu-sig.python.org/

Yes, I've especially used gmpy2 and met the maintainer at a user group, worked at Mentor Graphics as I recall, and was collaborating with Alex Martelli on getting Python such a library. Most of my Jupyter Notebooks exploring high precision are using that. Trig built right in, and complex numbers. Sage is a fantastic amalgamation of underlying tools, however I'm exploring what a plain vanilla or at most a small install of a 3rd party library (vs. a whole framework) might handle, as that lets us work in some simpler environments, maybe just a bash shell in some cases. I'm picturing tentative customers not pre-committed to using computers at all (e.g. high school math students used to Texas Instruments or maybe Casio). What's just one step away from a calculator? Calculators remain very convenient devices and are likely to stay useful in the field. I like those solar powered models. Nowadays more people emulate them on smartphones. Now that you've gone to all the trouble to upgrade to a real computer, lets at least establish you have decent power in the arbitrary precision department. What minimal setup would you need to prove that to yourself? That might help make you a convert if you're still thinking your calculator might be the more capable device to reach for. Lets do some circus tricks with Python, like 2**1000. Wow! Long integers are like a revelation. The actual answer! But can we do the same with messy decimal numbers? That's where too many settle for floating point, unnecessarily. But yes, lets not forget the towering achievements all around us here. We're indeed in a wealthy ecosystem. A lot of the barriers to adoption have to do with long ingrained habits of mind. The idea that we have both delta and lambda calculus now, i.e. the Newtonian calculus stuff and now Alan Turing and Ada stuff, is another way to help make it all one discipline, call it what you like. Kirby

On Wed, Jan 29, 2020, 5:59 PM kirby urner <kirby.urner@gmail.com> wrote:
Yes, I've especially used gmpy2 and met the maintainer at a user group, worked at Mentor Graphics as I recall, and was collaborating with Alex Martelli on getting Python such a library. Most of my Jupyter Notebooks exploring high precision are using that. Trig built right in, and complex numbers.
Sage is a fantastic amalgamation of underlying tools, however I'm exploring what a plain vanilla or at most a small install of a 3rd party library (vs. a whole framework) might handle, as that lets us work in some simpler environments, maybe just a bash shell in some cases. I'm picturing tentative customers not pre-committed to using computers at all (e.g. high school math students used to Texas Instruments or maybe Casio).
What's just one step away from a calculator? Calculators remain very convenient devices and are likely to stay useful in the field. I like those solar powered models. Nowadays more people emulate them on smartphones.
Now that you've gone to all the trouble to upgrade to a real computer, lets at least establish you have decent power in the arbitrary precision department.
What minimal setup would you need to prove that to yourself?
Are they working on Windows platforms? I understand that Python is in the Microsoft App Store now, but conda is not. Step one might be to get curl or wget and bash installed. Are admin rights required to get Windows Subsystem for Linux (WSL) installed? Apparently, 'certutil' can be used to download over http on Windows platforms: certutil.exe -urlcache -split -f " https://download.sysinternals.com/files/PSTools.zip" pstools.zip Then download and install Miniconda: - https://docs.conda.io/en/latest/miniconda.html <https://docs.conda.io/en/latest/miniconda.html> - https://docs.anaconda.com/anaconda/install/silent-mode/ certutil.exe -urlcache -split -f " https://repo.anaconda.com/miniconda/Miniconda3-latest-Windows-x86_64.exe" start /wait "" Miniconda3-latest-Windows-x86_64.exe /InstallationType=JustMe /RegisterPython=1 /S /D=%UserProfile%\Miniconda3 Then create an environment and install a few things: conda create -n maths jupyterlab spyder conda activate maths conda install -c conda-forge sympy gmpy2 matplotlib safe Then start jupyterlab or spyder or vscode, or IPython: jupyterlab spyder ipython # %logstart -o logged.inputandoutput.py But how do you plot 3d graphics in a terminal? In Jupyter notebooks, an object's _repr_html_ method will be called before just repr(object) (which calls __repr__) in order to get output for the notebook. TI-84 don't have CAS (because … not allowed because measuring) so that would be a cool demo.
That might help make you a convert if you're still thinking your calculator might be the more capable device to reach for. Lets do some circus tricks with Python, like 2**1000. Wow! Long integers are like a revelation. The actual answer! But can we do the same with messy decimal numbers? That's where too many settle for floating point, unnecessarily.
But yes, lets not forget the towering achievements all around us here. We're indeed in a wealthy ecosystem. A lot of the barriers to adoption have to do with long ingrained habits of mind. The idea that we have both delta and lambda calculus now, i.e. the Newtonian calculus stuff and now Alan Turing and Ada stuff, is another way to help make it all one discipline, call it what you like.
Kirby
_______________________________________________ Edu-sig mailing list -- edu-sig@python.org To unsubscribe send an email to edu-sig-leave@python.org https://mail.python.org/mailman3/lists/edu-sig.python.org/

On Thu, Jan 30, 2020 at 4:55 AM Wes Turner <wes.turner@gmail.com> wrote:
Are they working on Windows platforms? I understand that Python is in the Microsoft App Store now, but conda is not.
Yes. Oft times these are public school labs and I'm not in charge of what gets installed. Always Windows and/or Chromebooks. The private schools have featured Macs as well. However they're already using repl.it in the cloud (after Codesters in the sequence). My Decimal experiments have been in repl.it: https://repl.it/@kurner/tetravolumes I realize one may use Jupyter Notebooks in the cloud as well (e.g. that free Docker-based service etc., Mybinder I think it's called). But in this context I'm just sharing exhibits, saying "hit the run button" and showing it's at least as much fun as a calculator. Other exhibits might include Taylor Series or like that Ramanujan algorithm for 1/pi. Raspberry Pi is also feature in our curriculum segments. That comes with Wolfram Language perhaps, more like sympy and Sage, but if we can just dive in and use Decimal, so much the better (already installed with default OS). https://flic.kr/s/aHskYSMvKJ (Photo Album gives the flavor) Step one might be to get curl or wget and bash installed. Are admin rights
required to get Windows Subsystem for Linux (WSL) installed?
Apparently, 'certutil' can be used to download over http on Windows platforms:
certutil.exe -urlcache -split -f " https://download.sysinternals.com/files/PSTools.zip" pstools.zip
Then download and install Miniconda:
- https://docs.conda.io/en/latest/miniconda.html <https://docs.conda.io/en/latest/miniconda.html> - https://docs.anaconda.com/anaconda/install/silent-mode/
Useful on Raspberry Pi too I think. When I teach my 40 hours Python course to adults (I've got another one starting next week) I always go for conda. This is BYOD class i.e. they bring a mixed bag as to the OS -- and given teleteaching, I may not even know if they choose not to tell me. However, when it comes to this high precision fitting-together of puzzle geometric pieces, and giving a workout to that Gerald de Jong formula (came to him on a train in Holland I think it was, a Ramanujan Moment -- he's a math guy from University of Toronto [1]): that's for my younger students as well, and I'm not really in a position to micro-manage their computers either. Codesters doesn't implement decimal type (a deficiency in Skulpt and probably by extension in JavaScript?). However I can use it to import the graphics in question and display them on screen.
certutil.exe -urlcache -split -f " https://repo.anaconda.com/miniconda/Miniconda3-latest-Windows-x86_64.exe"
start /wait "" Miniconda3-latest-Windows-x86_64.exe /InstallationType=JustMe /RegisterPython=1 /S /D=%UserProfile%\Miniconda3
Then create an environment and install a few things:
conda create -n maths jupyterlab spyder conda activate maths conda install -c conda-forge sympy gmpy2 matplotlib safe
Then start jupyterlab or spyder or vscode, or IPython:
jupyterlab spyder ipython # %logstart -o logged.inputandoutput.py
But how do you plot 3d graphics in a terminal? In Jupyter notebooks, an object's _repr_html_ method will be called before just repr(object) (which calls __repr__) in order to get output for the notebook.
I've been a big VPython (Visual Python) fan over the years, as when it comes to 3d, I'm interested in Polyhedrons (e.g. Platonics etc), using user-crafted Vector classes and such. For years I relied on ray tracing i.e. Python code spit out scene description language. This approach became widespread e.g. see Antiprism by Adrian (antiprism.com). At my best, I was getting Game of Life on a 3D hexapent (with modified rules for 6 and 5 around 1). My Oregon Curriculum Network website is full of early VPython experiments (4dsolutions.net/ocn/cp4e.html). Kirby [1] Input six edges, get back out volume. Add 24 of this shape to that shape and prove outcome is 4.0 to 900 decimal places. Part of that repl.it thing. What I wrote up on Medium (linked top of this thread).

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 GarciaTeacher and ProfessorApplied Math, Physics and Computer Sciencehttp://shadowfaxrant.blogspot.comhttp://www.youtube.com/calcpage2009

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

Wow, Kirby, that's great! I've done something similar in java using the BigInteger class. I have to try the Decimal module in python! Looks like fun. I'm going to have to see how this works with MPI. Thanx, Al Sent from BlueMail On Feb 2, 2020, 19:18, 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

Here's how I used BigDecimal to find Phi, https://youtu.be/snk2IN3B2RI HTH, Al Sent from BlueMail On Feb 2, 2020, 19:18, 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

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 On Feb 2, 2020, 19:18, 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

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
participants (4)
-
A. Jorge Garcia
-
calcpage@aol.com
-
kirby urner
-
Wes Turner