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-and-beyond : > 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_mpfr.html 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.ur...@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.html > > 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-le...@python.org > https://mail.python.org/mailman3/lists/edu-sig.python.org/ >
_______________________________________________ Edu-sig mailing list -- edu-sig@python.org To unsubscribe send an email to edu-sig-le...@python.org https://mail.python.org/mailman3/lists/edu-sig.python.org/
