[HN Gopher] SymPy: Symbolic Mathematics in Python
       ___________________________________________________________________
        
       SymPy: Symbolic Mathematics in Python
        
       Author : tosh
       Score  : 208 points
       Date   : 2024-02-28 13:17 UTC (9 hours ago)
        
 (HTM) web link (www.sympy.org)
 (TXT) w3m dump (www.sympy.org)
        
       | westurner wrote:
       | SymPy: https://en.wikipedia.org/wiki/SymPy
       | 
       | - "How should logarithms be taught?" [with python and SymPy]
       | https://news.ycombinator.com/item?id=28518565#28519356
       | 
       | From "SymPy - a Python library for symbolic mathematics" (2020)
       | https://news.ycombinator.com/item?id=23767513 :
       | 
       | > _NumPy for Matlab
       | users:https://numpy.org/doc/stable/user/numpy-for-matlab-
       | users.htm..._
       | 
       | > _SymPy vs Matlab:https://github.com/sympy/sympy/wiki/SymPy-
       | vs.-Matlab_
        
       | lemursage wrote:
       | For a numerical "physicist" (yes, the quotation marks are
       | indispensable), Sympy was somewhat of a godsend to me. Great for
       | prototyping even more advanced models before optimising them
       | later on in C++.
       | 
       | I haven't used Mathematica much, but I have a feeling that it's
       | still more symbolically powerful (or requires less wrangling)
       | than SymPy? I'd appreciate if somebody with more experience in
       | Mathematica could lay it out flat for me if that's the case.
        
         | qsort wrote:
         | Stephen Wolfram notwithstanding, Mathematica is still far ahead
         | of most alternatives as a CAS. Maple is good on some integrals.
         | 
         | Their downsides are that their languages are not very well
         | suited as general purpose languages, many times the algebraic
         | manipulations you have to perform aren't that complicated and
         | you'd rather work in a "real" language.
         | 
         | Yet another case where python isn't the best in class but still
         | workable and able to benefit from its vast general-purpose
         | ecosystem.
        
           | llm_trw wrote:
           | Sagemath is a python library that has more capabilities than
           | Mathematica. If you want to do real symbolic computation in
           | python Sagemath is the only way to do it.
           | 
           | That said sympy is quite a cool little library for learning.
        
             | qsort wrote:
             | Sagemath isn't a python library, it's a collection of
             | packages (of which sympy is one) under a common interface.
             | It is indeed what you would use if you wanted to do real
             | symbolic computation in python, but it's not at the level
             | of Mathematica or Maple.
             | 
             | Look, we all love open source, but we aren't doing anybody
             | any favors by pretending the open source alternative is
             | better when it isn't. I would encourage anyone whose needs
             | are satisfied by sympy/sagemath to opt for the open
             | alternative, but the question was whether or not
             | Mathematica as of now, early 2024, is better. The
             | unfortunate reality is that it is.
        
               | llm_trw wrote:
               | I'm old enough to have had people tell me the same thing
               | about the Linux kernel vs the Windows kernel.
               | 
               | I can do an import sage as the top of any python script.
               | 
               | It's a library.
               | 
               | And since I get all of python for free it's better than
               | Mathematica.
        
               | 7thaccount wrote:
               | Your definition of "better" may be wildly different than
               | many. Mathematica is much better in many cases...
               | especially tasks where Mathematica has a built-in
               | function call for something that would be an absolute
               | pain in Python, but worse with respect to price and
               | licensing. I use Python a lot more than Mathematica, but
               | sometimes Mathematica is the best solution.
               | 
               | Your windows/Linux analogy is also not very relevant
               | here. Both are popular in different areas.
        
               | jfoutz wrote:
               | I think the windows linux analogy is pretty apt.
               | especially around the win95/98 days.
               | 
               | Getting some random laptop and figuring out what kernel
               | mods to enable and hope that the specific chipset
               | revision was supported, or maybe a patch available that
               | might work was, in fact, a lot of bullshit to put up with
               | to get, say, sound.
               | 
               | sympy will do a lot. but you're probably going to have to
               | reach for a big book of integrals, or find a friendly
               | mathematician to identify the equation and possible
               | approaches. Mathematica as a paid product has a lot of
               | time and effort spent avoiding resorting to asking for
               | help. Much much more built in.
               | 
               | As an undergrad or a hobbyist you probably want to stay
               | "lower" and slog through the calculations when you're
               | stuck. This is part of the process of understanding. But
               | as a professional, or a more advanced user, screwing
               | around for a week looking for a solution is a waste of
               | time and expertise. Spring the cash, and move forward
               | immediately.
               | 
               | I'm not trying to put words in your mouth, but I think
               | there is some nuance that this maybe helps people
               | understand your point.
               | 
               | "Better" really really depends on where you are and what
               | you're trying to do.
        
               | 7thaccount wrote:
               | I don't think many question that open source won't
               | eventually be equivalent or better than Mathematica for
               | computational work. It just isn't for a lot of things in
               | 2024. It might be fully reversed in another 5 years.
               | Agreed everyone's view of "best" is different as I said
               | above.
               | 
               | I will say a really nice thing about Mathematica is
               | consistency.
        
               | williamstein wrote:
               | Sagemath is a Python library (and a rather large one at
               | that). It's vastly superior to Mathematica and Maple at
               | some things (e.g., number theory and algebraic
               | combinatorics) and inferior at other things (e.g.,
               | symbolic integration).
        
           | behnamoh wrote:
           | "Python isn't the best tool for anything, but it's the second
           | best tool for most things."
        
             | alexdoesstuff wrote:
             | I thought the role of "second best tool for most things"
             | belonged to Excel
        
               | llm_trw wrote:
               | No, excel is the worst tool for anything.
        
               | QuadmasterXLII wrote:
               | "but you have heard of me"
        
               | StableAlkyne wrote:
               | Excel is the most popular GUI framework and programming
               | language in existence. And it underpins accounting
               | divisions around the world!
        
       | gunalx wrote:
       | Sympy is amazing, but i kinda fail to see whats news about it as
       | its oldest commit is 14 years ago.
        
         | 3pt14159 wrote:
         | I've never heard of it and I've been using Python since around
         | 2008, including mathematical stuff like Scipy / Numpy.
         | Sometimes people like to find old stuff and share it since it's
         | new to others.
        
         | kragen wrote:
         | python3 didn't exist 14 years ago, and neither did the ipython
         | notebook, and sympy has code specific to both.
         | /usr/share/doc/python3-sympy/changelog.Debian.gz on my laptop
         | shows six new versions in 02022, three new versions in 02021,
         | and eleven new versions in 02020. is it possible you're looking
         | at an outdated mirror of sympy?
         | 
         | oh, i see you said 'oldest commit'. well, what's news about
         | sympy is the 14 years of commits since then
         | 
         | https://news.ycombinator.com/newsguidelines.html says
         | 
         | > _On-Topic: Anything that good hackers would find interesting.
         | That includes more than hacking and startups. If you had to
         | reduce it to a sentence, the answer might be: anything that
         | gratifies one 's intellectual curiosity._
         | 
         | and, though it's not even stated, it includes more than news
        
         | zenburnmyface wrote:
         | Oldest commit was from today: https://github.com/sympy/sympy
         | 
         | Where are you getting 14 years from?
        
           | whyever wrote:
           | That's the youngest commit.
        
             | okutanski wrote:
             | Some say Potato others say Tomato it's a british vs.
             | american thing
        
           | magnio wrote:
           | That's the newest commit. The oldest commit on GitHub is from
           | 2007: https://github.com/sympy/sympy/commit/99b21ff58ad2e2ba8
           | 31725...
        
           | lambdas wrote:
           | You wouldn't say "my oldest child was born today" in
           | reference to your family of six children born between 2008
           | and today though.
        
       | QuadmasterXLII wrote:
       | SymPy gets the job done. I typically use it in the SageMath combo
       | library, is that still the way to go or has SymPy advanced to the
       | point that I should be using it on its own?
        
         | Aardwolf wrote:
         | SageMath looks cool, but the fact that it's a combination of
         | many different existing tools all with their own syntax, and
         | feature overlap, scares me off a bit since it seems like how
         | you do things wouldn't be very internally consistent
         | 
         | How does this aspect work out in practice?
        
           | QuadmasterXLII wrote:
           | In practice it feels like working with three libraries in a
           | trenchcoat. However, as of five years ago it was totally
           | worth it: the killer app for Sage was that it let you
           | describe a problem in SymPy where you have the full power of
           | python for loops, library support, visualization etc; and
           | then solve it with Maxima's more powerful symbolic calculus
           | tools. I'm not up to speed on whether SymPy has caught up to
           | Maxima in terms of being able to solve integrals,
           | differential equations, etc.
        
       | idanp wrote:
       | I use SymPy as my calculator with
       | https://github.com/idanpa/calcpy
        
         | Hugsun wrote:
         | This looks perfect. I've found native sympy to be a little
         | cumbersome to use.
        
           | qorrect wrote:
           | Same here, I've been slogging through with raw sympy this
           | tool looks great.
           | 
           | How do I speed up the start time for it - any ideas?
           | Recompile it with PyPy or similar?
        
             | idanp wrote:
             | I think PyPy usually has slower startup time. Need to try
             | to defer some of the imports to be done in the background,
             | see how good is the outcome. Feel free to open an issue in
             | github.
        
         | throw4023042q0 wrote:
         | this project is AWESOME! cool idea man
        
       | abricq wrote:
       | Working in the field of robotics, I often have to write big
       | vectors ( _usually computed as the result of 3D transformations_
       | ) and then compute their Jacobian ( _their derivative with
       | respect to several state-variables_ ), which quickly becomes very
       | nasty equations. I use sympy to (i) compute these big vectors,
       | expressed in a very declarative way, (ii) compute the jacobian
       | and (iii) export the results in C-code, immediately importable in
       | my code case.
       | 
       | To illustrate what I mean by "expressing systems of equations in
       | a declarative way", here is a toy-example of how to estimate the
       | position of the a sensor with respect to a robot's center if you
       | have access to a dataset containing robot positions and the
       | sensor positions. The 'naive' approach (it very often works) is
       | to solve an over-constrained system with a gradient-descent. To
       | perform a gradient descent, you need a residual function and its
       | jacobian. Here's how you would do to compute it with Sympy. (
       | _Note: you 'd just have to define the `transform` and `invert`
       | functions..._)                   # Pose of a sensor in robot
       | frame (to be estimated)         xa, ya = symbols("xa, ya")
       | a = Matrix([xa, ya, ta])              # Position of the robot at
       | time t         rx, ry, rt = symbols("rx, ry, rt")         rk =
       | Matrix([rx, ry, rt])                  # Measure of the sensor at
       | time t         gx, gy = symbols("gx, gy")         gk =
       | Matrix([gx, gy, 0])                  # Estimated x (from the
       | measures)         estimated_a = transform(invert(rk), gk)
       | # compute the norm of the gk, squared         n2_mat =
       | norm2(estimated_a - a)         n2 =
       | sympy.collect(sympy.expand(n2_mat[0, 0]), a).simplify()
       | # Compute the jacobian         J = n2_mat.jacobian([xa, ya, ta])
       | # Print what is necessary for Guass-Markov regression
       | print("\n\nres =", n2)         print("\nJacobian = ", J)
        
         | mattivc wrote:
         | You might find this library interesting:
         | https://github.com/symforce-org/symforce
        
         | whyever wrote:
         | Why are you calculating the Jacobian symbolically? AFAIK, for
         | complex cases, the numerical Jacobian is often faster / more
         | numerically stable.
        
           | abricq wrote:
           | Well, the symbolic computation is only used to generate C
           | code. The generated code then evaluates jacobians
           | numerically. And we use several methods for numerical
           | stability on top of that.
        
           | funks_ wrote:
           | Especially if you actually require vector-Jacobian or
           | Jacobian-vector products instead of the full Jacobian.
        
           | eutectic wrote:
           | I though finite difference differentiation was notoriously
           | unstable.
        
             | legobmw99 wrote:
             | Perhaps the commenter means something like reverse mode
             | automatic differentiation?
             | 
             | Finite differences does indeed have stability issues, and
             | even if you apply some tricks will only give you about half
             | float precision
        
           | mitthrowaway2 wrote:
           | The poster is talking about using symbolic math to obtain a
           | closed-form expression for the Jacobian that is then
           | numerically evaluated. This will often be faster and more
           | accurate. For example, if your function is sin(x), then the
           | symbolic math tells you your derivative is cos(x), so you put
           | that expression in your code and compile it. When calling
           | this on the angle x = 0.123, your code then just evaluates
           | numerically cosf(0.123), rather than (sinf(0.124) -
           | sinf(0.122)).
        
           | toolslive wrote:
           | There are plenty of situations where the scenario goes like
           | this: you first do symbolical calculations. then fill in some
           | of the free variables, your resulting expression will
           | simplify a lot. Then you compile that resulting expression to
           | native code and evaluate the simplified specialized code for
           | a zillion parameter vectors.
           | 
           | Anyway,if your day job needs something like this you're
           | better off using a lisp than python.
        
         | exDM69 wrote:
         | I've used SymPy in a very similar way, in my case it was some
         | nasty derivatives that were needed for some orbital mechanics
         | calculations.
         | 
         | First write down the equations, then let SymPy do the laborious
         | math part and turn the output into C code.
         | 
         | I'm guessing this is why you don't see a lot of SymPy projects
         | in the wild. It was used for some intermediate calculations,
         | and the results were turned into the product's code and the
         | symbolic code is thrown away.
        
           | analog31 wrote:
           | There might be a better way, but my habit is to include the
           | symbolic code as a comment in the C. I've thanked myself for
           | doing this.
        
             | abricq wrote:
             | I commit the symbolic code on its own file, in the same
             | commit which adds the c code.
        
               | lucioperca wrote:
               | I guess a hypermodern solution would be to produce the
               | parts of the C code with CI/CD from the SymPy Code.
        
         | tehsauce wrote:
         | Have you considered using jax? you can efficiently compute the
         | jacobian (even using the gpu if you want) without leaving
         | python at all. The api is also numpy compatible!
        
           | abricq wrote:
           | We target very low-level & specific hardware. I don't think
           | it would be easy to deploy Jax on it. But it's an interesting
           | idea, maybe for robots running linux !
        
         | eutectic wrote:
         | I just did this exact thing today, writing a cloth simulator! I
         | wanted to try updating each node position in turn using a
         | Newton step, holding the other nodes fixed.
        
         | fho wrote:
         | Funfact: you can probably JIT compile that using JAX for an
         | easy performance gain.
        
           | 6gvONxR4sf7o wrote:
           | But then they would have to compile the jit-optimized XLA to
           | C. Do you know if that's straightforwardly doable?
        
         | sampo wrote:
         | > I use sympy to (i) compute these big vectors, expressed in a
         | very declarative way, (ii) compute the jacobian and (iii)
         | export the results in C-code, immediately importable in my code
         | case.
         | 
         | You could maybe calculate the Jacobian in C code using
         | automatic differentiation. Might be less C-code, might be less
         | elementary operations done in the C code, and you would not
         | need to be copy-pasting complex symbolically derived formulas
         | from Python to C.
         | 
         | https://en.wikipedia.org/wiki/Automatic_differentiation
        
           | whatshisface wrote:
           | I could be wrong, but I seriously doubt C macros can do this.
        
             | sampo wrote:
             | Why are you thinking of macros?
        
               | whatshisface wrote:
               | In an embedded environment you would want it to be pre-
               | compiled and optimized.
        
         | dimatura wrote:
         | Yes, back in the day I saw people doing this with Maple, glad
         | there's open source options now. There's a cool library (also
         | using Sympy) to do this kind of thing in robotics and computer
         | vision applications, symforce https://github.com/symforce-
         | org/symforce
        
       | treprinum wrote:
       | Is there any GUI for SymPy one could easily use to solve symbolic
       | math like Maple/Maxima/Macsyma?
        
         | jks wrote:
         | You can run it in Jupyter notebook. They have a lightweight
         | implementation of that at https://live.sympy.org/ but the
         | closest counterpart to Maple would probably be SageMath, which
         | includes sympy and a lot more. https://www.sagemath.org/
        
         | whyever wrote:
         | Not sure what you mean with GUI, but you can use it with
         | Jupyter notebooks.
        
           | treprinum wrote:
           | More like writing/clicking math (like in MS Word or some
           | LaTeX editors) that is then converted to SymPy instead of
           | writing stuff in Python directly.
        
             | sorenjan wrote:
             | It should be relatively straightforward to build something
             | with Visualequation, latex2sympy, SymPy, and maybe
             | IPython's QTConsole.
             | 
             | https://github.com/daniel-molina/visualequation
             | 
             | https://pypi.org/project/latex2sympy2/
             | 
             | https://ipython.org/ipython-
             | doc/2/interactive/qtconsole.html
             | 
             | Edit: That might be overcomplicating things, there are
             | already better alternatives:
             | https://tex.stackexchange.com/questions/57068/wysiwyg-
             | latex-...
        
         | notpushkin wrote:
         | Would Jupyter do the trick? https://jupyter.org/
        
         | BD103 wrote:
         | You might find SymPy Gamma interesting:
         | https://www.sympygamma.com
        
         | westurner wrote:
         | JupyterLite's default Python-compiled-to-WASM build has NumPy,
         | SciPy, matplotlib, and SymPy installed; so you can do computer
         | algebra with SymPy in a browser tab.
         | 
         | https://JupyterLite.rtfd.io/
         | 
         | https://github.com/jupyterlite/jupyterlite/tree/main/py/jupy...
         | :
         | 
         | > _Initial support for interactive visualization libraries such
         | as: altair, bqplot, ipywidgets, matplotlib, and plotly_
        
       | kragen wrote:
       | sympy works really well in jupyter. my own demo notebooks for
       | sympy are
       | 
       | https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/sympy...
       | (solving a multivariate quadratic with math pretty-printing)
       | 
       | https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/tiny-...
       | (my cheatsheet of quick-and-dirty numpy/pylab plots, including
       | some sympy examples)
       | 
       | https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/secan...
       | (using sympy to symbolically differentiate an existing python
       | function, which is something you can't usually do, in order to
       | find its minimum in closed form)
       | 
       | https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/max-p...
       | (some basic circuit analysis with basic calculus with sympy)
       | 
       | https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/latex...
       | (various fiddling around with mathjax formatting and sympy,
       | including some analysis of minsky's circle algorithm from hakmem)
        
       | tableofzero wrote:
       | There is a benchmark of Sympy vs Mathematica at
       | https://www.12000.org/my_notes/CAS_integration_tests/reports...
       | 
       | The results were Mathematica failed to solve 1,523 problems,
       | Sympy failed to solve 48,529.
       | 
       | So it has some catching up to do.
        
         | wiz21c wrote:
         | Although super interesting, the website you mention is only
         | about integrals...
        
           | Affric wrote:
           | I mean, integrating is one of the operations you might want
           | particular help with. Especially for integrands without
           | elementary function integrals.
        
         | wiz21c wrote:
         | Do you know why there's such a big difference ? For example, is
         | the way sympy does its job fundamentally flawed ?
        
           | epistasis wrote:
           | I doubt there's any sort of fundamental flaw in sympy.
           | Getting more and more solutions is mostly about putting in
           | lots of work to tweak the bag of tricks. There is no
           | universal algorithm for solving integrals.
           | 
           | As an open source project depending on volunteers (or is it
           | just the one major author?) I am impressed that sympy does as
           | much as it does.
        
             | jcla1 wrote:
             | > There is no universal algorithm for solving integral.
             | 
             | Not that I want to dispute this, but depending on what you
             | meant, there is in fact such an algorithm:
             | https://en.wikipedia.org/wiki/Risch_algorithm
             | 
             | Though often it is not implemented because it is quite
             | complex (its details covering two thick books) and many of
             | the special cases it covers rarely crop up in the real
             | world, so the effort isn't worth it.
             | 
             | The caveat of Risch's algorithm is that it only "works" if
             | the function you are trying to integrate has an elementary
             | antiderivative. Many of the problems that Mathematica can
             | solve (but SymPy fails at) involved special (i.e. non-
             | elementary) functions.
        
               | epistasis wrote:
               | That is an excellent caveat, and well cited, thanks.
        
           | WoahNoun wrote:
           | It's a running joke that Wolfram is a jobs program for math
           | PhD's. The difference isn't necessarily technical, but the
           | sheer amount of labor that has gone into adding more edge
           | cases and niche use cases. Sympy is great but like most open
           | source, it's created by volunteer maintainers supported by
           | donations.
           | 
           | I imagine the difference is even bigger in things like
           | solving ODE's/PDE's.
        
             | Qem wrote:
             | > It's a running joke that Wolfram is a jobs program for
             | math PhD's.
             | 
             | Nice. The PhDs just need take care their contributions
             | aren't misappropriated. See
             | https://en.m.wikipedia.org/wiki/Rule_110
        
           | pquki4 wrote:
           | I mean, literally people with Math PhDs are being paid to
           | work on the product, full-time. And they have a financial
           | incentive to address feedback from customers and try to solve
           | as many problems as possible.
           | 
           | By comparison, open source projects are developed by people
           | with a wide range of knowledge level and commitment, and you
           | simply can't expect the quality to be the same.
           | 
           | I find that discussions on HN often fail to acknowledge that
           | proprietary software is usually _extremely_ good at their
           | domain, and what companies put into UX, support and the
           | development /feedback loop are actually very valuable.
        
             | Affric wrote:
             | Yep. Know a few in the math department that have worked on
             | Mathematic. Don't know any who have worked on SymPy.
        
         | StevenXC wrote:
         | SymPy is open source, mathematica is not.
         | 
         | Additionally, SageMath (which depends on SymPy) is the more
         | comparable product (and is open source).
        
           | bmitc wrote:
           | > SymPy is open source, mathematica is not.
           | 
           | Why does that matter?
        
             | in9 wrote:
             | 1) free
             | 
             | 2) able to be around if a single CEO isn't around (Wolfram)
             | 
             | 3) able to continue if the supporting company is not
             | profitable anymore
             | 
             | 4) possibility of greater oversight if popularity rises
             | 
             | 5) extensible if one puts the effort into it
        
       | bluish29 wrote:
       | A decade ago when I was interested in General Relativity I wanted
       | to write a simple program to handle symbolic calculations for
       | Einstein field equations (Starting with metric and calculated
       | affine connections, ricci tensor ...etc.). Sympy was an option
       | (better because python was the only language I know well) but I
       | found it hard and actually couldn't make it work. I used
       | mathematica which was new for me but did it in a couple of hours.
       | I expanded it later and used it to calculate a lot of things in a
       | black hole paper I published later.
       | 
       | I checked now, and it seems that on this front a lot of
       | development in sympy made it possible that we know how very good
       | libraries built on top of it [1] [2]. There is even now a Jupyter
       | notebook example on schwarzschild metric [3].
       | 
       | [1] https://docs.einsteinpy.org
       | 
       | [2]https://github.com/spacetimeengineer/spacetimeengine
       | 
       | [3]
       | https://github.com/sympy/sympy/blob/master/examples/intermed...
        
         | dsqrt wrote:
         | You should check out Sage Manifolds [1]. It's built on top of
         | Sage Math, but I think it can also use SymPy as computational
         | engine.
         | 
         | [1] https://sagemanifolds.obspm.fr/
        
       | ivan_ah wrote:
       | SymPy is awesome indeed! I've been using it as a teaching tool
       | for many years. IMHO, it's the best option as compared to
       | Mathematica/Maple/etc. because the API functions match exactly
       | the verbs students use when learning math (solve, expand, factor,
       | etc.).
       | 
       | Here is a little tutorial for anyone looking to get started:
       | https://minireference.com/static/tutorials/sympy_tutorial.pd...
       | 
       | Also available in runnable notebook format:
       | https://colab.research.google.com/github/minireference/sympy...
       | (read only =
       | http://nbviewer.ipython.org/github/minireference/sympytut_no... )
       | 
       | Last but not least, for anyone interested in trying SymPy without
       | installing anything, there is always the SymPy live shell:
       | https://live.sympy.org/ (runs Python + SymPy in the browser
       | thanks to WebAssembly)
        
         | bloaf wrote:
         | The biggest drawback of SymPy is the need to pre-define all
         | your symbols. That makes it more difficult to handle scenarios
         | where you're taking formulas as input because you either need
         | to parse the equation yourself to figure out what variables
         | were used, or have the user manually supply the symbols.
        
           | staplung wrote:
           | Might not handle exactly the difficulties you're having but
           | you can do `from sympy.abc import *`. This will create
           | symbols for pretty much all letters (lower and upper) as well
           | as a bunch of greek symbols (but written out, e.g. "delta").
        
             | bloaf wrote:
             | Imagine a scenario where you've got a database of
             | timeseries data, say stock prices. Each price trend is
             | identified by the stock ticker, and your users have an
             | excel spreadsheet of several thousand equations in terms of
             | the stock ticker (e.g. (AAPL-TSLA)/AAPL) and you want to
             | calculate the derivative of each one of those equations
             | with respect to each ticker symbol in each equation before
             | pulling the data.
             | 
             | Obviously you _could_ find a list of every ticker symbol
             | and create a few thousand symbols before parsing, but you
             | don 't always have the luxury of a complete/up-to-date
             | list, or doing so might create too many symbol objects and
             | cause performance problems.
        
           | rav wrote:
           | There `isympy -I`, which runs an IPython REPL with a
           | preprocessor that changes unknown variables into sympy
           | symbols, but that only helps you for interactive usage.
        
           | throw4023042q0 wrote:
           | I usually run a pre-processing step to identify all needed
           | symbols and then create them dynamically. I find sympy works
           | fine for such on-the-fly workflow. My experience is with
           | predictive statistics and financial models.
        
       | cpp_frog wrote:
       | Symbolic mathematics is severely underexplored in undergraduate
       | studies, and the little exposure I had was generally tied to
       | proprietary software such as Mathematica and MATLAB. I learned to
       | use it as an imperfect extension of pen-and-paper thinking, and
       | source code for more advanced stuff gets shaky the deeper into
       | abstraction one goes. For example, I work in a field of
       | mathematics/engineering that requires heavy use of tensor
       | calculations. My go-to tool for that is Maxima, however, it has
       | limited and cumbersome packages for it (see [0]). Now for more
       | sophisticated calculations I resort to SymPy, not necessarily
       | because of better handling of symbolics but because of the
       | abstractions that Python already has. Maybe someday I'll get to
       | read the _Principles_ by Norvig and fix Maxima to suit my needs
       | (if anyone has better references to read Maxima 's source
       | code/implementation of tensor computations/symbolic (tensor,
       | geometric) algebra I would be grateful to know).
       | 
       | [0] https://arxiv.org/pdf/cs/0503073.pdf
        
         | Ginger-Pickles wrote:
         | For great justice, does anyone know of any applications (other
         | than Maple) that support WYSIWYG typeset _input_ (not output)
         | like Maple does?
         | 
         | As far as I know, Wolfram/Mathematica, LaTex, SymPy, Jupyter,
         | Sage etc all rely on typewriter text for composing and
         | inputting math. For this (and only this) reason, Maple is the
         | only application that ever resonated with me, because input may
         | be written in the same form it's written by hand, and it's
         | baffling this capability isn't more commonplace. Is this a
         | barrier to anyone else?
        
           | unicas wrote:
           | There's a lot of them. In principle every CAS that has a
           | TeXmacs interface can do it (FriCAS, Maxima, Reduce ... oo).
           | E.g. https://news.ycombinator.com/item?id=19465270.
        
         | jxramos wrote:
         | a close friend of mine used to tell me about these production
         | Mathematica Notebooks he'd author at his company Coherence to
         | do all these optical and thermal calculations with. It was a
         | regular workhorse for him.
         | 
         | A very long time ago I used to play around with Derive5 in my
         | youth. It was the most affordable Computer Algebra System (CAS)
         | of the time and I learned to program in that funky one liner
         | programming language where I had to strip all the white space
         | from my editor and always be careful to balance parenthesis. I
         | should dig up those old files and upload them to my github.
         | I've been actually meaning to reimplement those operations in a
         | more modern CAS system and see if I can more densely plot these
         | curves I was studying with some iso-arc-length families of
         | exponentials about the point (0,1).
        
       | manojlds wrote:
       | As an aside - I have a bunch of logical expressions and I need to
       | see if they are mutually exclusive. As in, if one is true given
       | some combination of the variables, none of the other expressions
       | must be true for the same combination.
       | 
       | For example Country="US" and Type="Sales" is not exclusive with
       | Type in ("Sales", "Purchase")
       | 
       | What would be an approach to solving this?
        
         | pizza wrote:
         | Maybe prolog (or other logic programming language) or z3 (or
         | other SAT solver)?
        
         | jlokier wrote:
         | If your logical expressions aren't too strange, and there
         | aren't too many, that's well suited to an SMT solver, such as
         | Z3.
         | 
         | You might, for example, create a new logical expression for
         | each pair of your original expressions, joining each pair with
         | AND, and then join those AND pairs with OR. Then ask the SMT
         | solver to generate an unsatisfiability proof.
        
       | chpatrick wrote:
       | Super useful package. I hate working out maths by hand so I
       | usually use it whenever possible.
        
       | maxboone wrote:
       | Use this extensively when doing linear algebra and when I'm too
       | lazy to do it by hand, very useful tool indeed!
       | 
       | Especially the print(latex(...)) command has helped a ton to
       | write large matrices in notes for courses.
        
       | whizzter wrote:
       | It's a seriously cool way to solve problems, never used it but
       | discovered that the winner of one of the Advent of Code days in
       | 22 or 23 basically just set up equations with SymPy and let it
       | solve everything beating out the usual cadre of "fast-hackers" in
       | the top.
        
       | WanderPanda wrote:
       | I wish Symbloics.jl 's rewriting/simplification rules were as
       | good as SymPy's/Matlab's. The composability of the Julia
       | ecosystem would be really great for symbolic math
        
       | bowsamic wrote:
       | Unfortunately I always found it quite slow compared to
       | Mathematica
        
         | whyever wrote:
         | That's a known problem and somewhat mitigated by symengine:
         | 
         | https://github.com/symengine/symengine
        
         | Qem wrote:
         | It's pure Python, so you can run it under PyPy.
        
       | verdverm wrote:
       | SymPy was instrumental to my PhD implementation, mainly for
       | simplifying math expressions. Nothing was even close at the time
       | 
       | https://github.com/verdverm/pypge
        
       | rpep wrote:
       | I used it for this during my PhD: https://github.com/rpep/fmmgen
       | and found it very powerful.
       | 
       | I have in the past used Mathematica, which I did think was more
       | powerful for symbolic math to be honest, but it had the downside
       | of not being free...!
        
       | hackerbrother wrote:
       | I used this to calculate answers for calculus worksheets in LaTeX
       | format in grad school.
        
       | tverbeure wrote:
       | When you ask ChatGPT 4.0 symbolic mathematical questions, it uses
       | sympy under the hood, and you can get the script that generated
       | the answer. It's great.
        
       ___________________________________________________________________
       (page generated 2024-02-28 23:00 UTC)