SymPy: Symbolic Mathematics in Python | Hacker News Reader

SymPy: Symbolic Mathematics in Python

sympy.org

264 pointstosh133 comments

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)

You might find this library interesting: https://github.com/symforce-org/symforce

Was just going to suggest that! I’ve only recently started using it but so far it has been excellent. One tip… the code generator seems to do a lot of cleaning and simplification. Just today I had some ugly equations that took up many pages of Jupyter output but the generated C++ code was only about 150 lines and didn’t look particularly inefficient. It seemed to me on inspection that it found repeated product and sum terms and properly computed them once and stored them in scratch variables.

Why are you calculating the Jacobian symbolically? AFAIK, for complex cases, the numerical Jacobian is often faster / more numerically stable.

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.

Especially if you actually require vector-Jacobian or Jacobian-vector products instead of the full Jacobian.

I though finite difference differentiation was notoriously unstable.

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

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)).

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.

For those of us that have never touched lisp - can you explain why?

Lisp has quote, unquote, and friends allowing you to turn code into data, then manipulate it and then turn it back into code. These are all the tools you need to create on-the-fly compilers. Here's an article explaining the lost art:

http://gms.freeshell.org/peval.html

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.

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.

I commit the symbolic code on its own file, in the same commit which adds the c code.

I guess a hypermodern solution would be to produce the parts of the C code with CI/CD from the SymPy Code.

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!

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 !

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.

Funfact: you can probably JIT compile that using JAX for an easy performance gain.

But then they would have to compile the jit-optimized XLA to C. Do you know if that’s straightforwardly doable?

Hmm ... Good question. I would assume that JAX and XLA is based on LLVM (like everything else these days) and that you could probably grab the IR at some point to compile it to your target.

Numba would probably do the job too

> 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

I could be wrong, but I seriously doubt C macros can do this.

Why are you thinking of macros?

In an embedded environment you would want it to be pre-compiled and optimized.

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

I tried to use SymPy for a similar problem: computing the Jacobian of a complicated integral using quaternion rotations.

Problem was that the symbolic results were way too complicated and the simplify function didn't help much. So, I got back to manual differentiation.

I'm not familiar with this field but is this similar to an Extended Kalman Filter?

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)

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.

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").

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.

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.

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.

Glad to see some tutorials!

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

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?

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.

MathCad works this way also, IIRC.

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).

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.

Although super interesting, the website you mention is only about integrals...

I mean, integrating is one of the operations you might want particular help with. Especially for integrands without elementary function integrals.

Do you know why there's such a big difference ? For example, is the way sympy does its job fundamentally flawed ?

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.

> 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.

That is an excellent caveat, and well cited, thanks.

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.

> 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

It's funny you should say that. Wolfram himself tried to take credit for the concept of cellular automata.

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.

Yep. Know a few in the math department that have worked on Mathematic. Don’t know any who have worked on SymPy.

You mean they were Mathematica customers. Academics are incentivized to use proprietary solutions as those solutions tend to be best-in-class and also offered at a discount.

No, I mean I am yet to meet a person who has done development on SymPy (that I can recall) but I know a few academics that came from working for Wolfram on Mathematica itself.

Thank you for allowing me to disambiguate.

That's interesting. You should consider yourself lucky to have met Wolfram employees, as they are obviously vastly outnumbered by users of Mathematica.

I have not met any developers for either of these products but I know that SymPy has a huge list of contributors for a project of its size. See: https://github.com/sympy/sympy/blob/master/AUTHORS

You may not be hearing about SymPy users because SymPy is not a monolithic product. It is a library. If you know mathematicians big into using Python, they are probably aware of SymPy as it is the main attraction when it comes to symbolic computation in Python. They wouldn't necessarily spit out a bunch of libraries in the same breath as "I use Python."

I have been playing around with SymPy for the last couple of weeks because the CompSci department (not entirely uncontroversially) wants to become Python native for the students to make the courses more accessible. I have been looking into ways to incorporate SymPy and SageMath into my tutoring for the mathematics for comp sci students type units.

1261 is an impressive number of contributors. I am interested to see if I could round up some people to hack up some of these test failures.

I know that but the idea behind my question was this: the knowledge we need to put in such a program doesn't move as fast as the program evolves. Therefore, given enough time (say 20 years), the open source solutions will cover more or less the same ground as the expensive solution. Of course the expensive one may always have an edge but that edge should get smaller over time. For example, Oracle remains a gold standard, really expensive but postgres covers many needs. Linux-on-the-desktop is also quite good, although not as good as, say, MacOS.

In the same vein, I was expecting SymPy to be like 80% of Mathematica but the given benchmark says it's about 25%. So I was suprised.

And I'm not thinking about UX, support, etc. which are indeed not often very good because, I guess, people prefer to put their energy in things that have the bigger leverage.

SymPy is open source, mathematica is not.

Additionally, SageMath (which depends on SymPy) is the more comparable product (and is open source).

> SymPy is open source, mathematica is not.

Why does that matter?

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

And that matters if you are mostly worried about value, to a large extent. If you are evaluating "better" as in "supports more symbolic operations," none of those really enter into it? Right?

This is like opining that the best "car" out there is a gokart you can get complete schematics on, for all of these reasons. I think most of us would accept the argument that the better cars are the ones that pass metrics aimed at cars. In this analogy, the better algebra system is the one that does the most algebra.

If SymPy meets your needs, it is objectively better. Mathematica is expensive and you probably have to pay for licenses on a continuous basis for every instance you use. Many benchmarks are stress tests and not representative of common work.

Objectively better in what sense? There is an objective cost in the initial installation, yes.

Additionally, Mathematica is not really that expensive.

It's not just initial installation. I have not pursued a license lately but these kinds of products cost money for every running instance. Institutions often have license servers on premises that allow a fixed number of people to use the stuff at once. If you use a SDK to build a program with it, that's got a separate license. If you need it for a real product, we are generally talking like thousands of dollars per developer per year in perpetuity, plus god knows whatever you use for SaaS. You might have to negotiate a price for your use case.

This is kind of silly, though? Yes, if you do not need a full car, a bike may fit your needs. The bike is still not a better car, though.

You can try to broaden it to saying it is a better vehicle for you. And, sure, for a lot of folks the cost will be important there. As a CAS, though, Mathematica is tough to beat.

No it's not silly. A Lamborghini might be a better performing vehicle that could solve problems I didn't even know I had, but if I don't have the money for it and/or a Ford Pinto covers 99% of the cases I need, the Pinto is better.

I'm not arguing that SymPy is going to beat Mathematica on benchmarks. But if both of them meet your needs, and you like having money and/or control of the code, SymPy wins.

So, in this we don't really disagree. But, I would only agree that it is an objectively better choice for you. It is not an objectively better CAS. Demonstrably so, per that benchmark.

Similarly, a lamborghini is almost certainly an objectively faster car. Such that if you were discussing fast vehicles and someone pointed out that their ebike was good enough for them, it would be a statement out of nowhere that is not using the rubric for ordering that was being discussed. Are they wrong that the ebike is a better choice for them? Almost certainly not. Would it be valid to say that it is the best fast vehicle because of that? (I say this as someone that loves bikes and is fairly anti car...)

And there would be other rubrics that would shine light in either direction regarding python. Arguably, the stewardship of the language lost a lot of trust with people in the hilariously bad 2->3 migration. More so in how bad dependency management has become. Yes, you can roll your own, but people with large support contracts can almost certainly offload a lot of that to the team on Mathematica, if that is truly a concern.

(I could similarly cast shade on Mathematica, but I think my point is made. Yes, you can have a rubric that changes which is the better choice for a situation. No, there is no total ordering of correct choices.)

We are essentially in agreement. I just don't think Mathematica is worth the money unless you need it for something specific like solving tricky problems. As much shade as you can throw on Python, there are lots more possibilities to use Python with SymPy than to use Mathematica. Unfortunately, the cutting edge FOSS math scene will always lag behind the commercial tools, as it is incredibly hard for them to get donations. I remember hearing a story about the developer of Octave (the most popular Matlab clone). He had worked on it for years and hardly got any donations, despite probably having hundreds of thousands of downloads and constant feature requests.

Indeed, I think we are fairly aligned.

I also think the math systems will lag for more than just donations. The work to make a good CAS is pretty intense. A lot like a good SAT system. Or really anything that is deep in the weeds of computer science. A lot of us are so far removed from the math that they focus on, that it can be mind bending to try and get back into it. (Indeed, for a lot like me, we were probably never really great at it, in the first place.)

Mathematica and Matlab are interesting to consider, as they are likely very well integrated into older workflow systems from the mainframe era. In particular, I'd expect the high end simulations for car and vehicle designs are much more integrated with those than anything open source. And a lot of that is largely availability of what they are integrating with. Most of us do not have the science labs and all of the equipment that goes with it.

Which, I think, is a bad feedback loop on this. For folks without those labs, Mathematica/Matlab are prohibitively expensive. For those with the labs, they are probably a rounding error. And there is no real path from the current equilibrium to one that can get it to more people. (The old path was free access in college. But that is becoming less of a thing in modern programming jobs.)

(1) is true, but Mathematica is also supported because it is paid. (2), (3), and (4) are very iffy stances. Open source projects also fail when leaders move on, and it's actually less likely for a company. (5) has nothing to do with open source, and Mathematica is extensible.

I ask because I always see open source thrown around as if it's some paragon of quality and productiveness. In reality, the actual usefulness of a product is fairly independent of its open source status. And rarely does it matter all that much to a project that a software component is open source or not.

I'm a mathematician. One reason it matters to me is that if I write a program that computes something in a proof, I need to be able to understand and verify (or possibly check that other people I trust have verified) the source and algorithms.

I have also modified and extended open source implementations in sage to work with cases I needed. And I've added some of this back to sage.

It is undeniable that Mathematica evaluates crazy integrals better than most other tools. But it will happily output complete nonsense. And you can't check!

> One reason it matters to me is that if I write a program that computes something in a proof, I need to be able to understand and verify (or possibly check that other people I trust have verified) the source and algorithms

Do you actually do this verification? How do you accomplish this? The software stacks are huge. Why do you trust other people over the people who develop Mathematica, who just happened to be paid?

Yes, I do. And open source software can have papers and algorithms documenting various aspects. This is very much like using results of other math research papers, in that there is communal review and trees of dependencies and everything can be cross-verified.

It is also true that, just like with a generic math research paper, that I don't check every claim of every step of every implementation of every algorithm in the process. But checking is possible, and when we find errors (which we do frequently) we can look and try to explain what it happening.

But when we find errors in tools such as Mathematica, we cannot. We report the errors and then know nothing more. (And sometimes the errors are never fixed).

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

I use SymPy as my calculator with https://github.com/idanpa/calcpy

This looks perfect. I've found native sympy to be a little cumbersome to use.

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?

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.

this project is AWESOME! cool idea man

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)

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...

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/

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.

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.

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.

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.

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.

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.

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.

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.

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).

"Python isn't the best tool for anything, but it's the second best tool for most things."

I thought the role of "second best tool for most things" belonged to Excel

No, excel is the worst tool for anything.

"but you have heard of me"

Excel is the most popular GUI framework and programming language in existence. And it underpins accounting divisions around the world!

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?

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?

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.

Is there any GUI for SymPy one could easily use to solve symbolic math like Maple/Maxima/Macsyma?

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/

Not sure what you mean with GUI, but you can use it with Jupyter notebooks.

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.

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-...

Would Jupyter do the trick? https://jupyter.org/

You might find SymPy Gamma interesting: https://www.sympygamma.com

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

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

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.

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.

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?

Maybe prolog (or other logic programming language) or z3 (or other SAT solver)?

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.

Thanks the suggestion was very useful and I am even close to having a prototype. Z3 is cool!

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...!

I started work on a new computer algebra system in Rust that has Python bindings: https://symbolica.io/

For many operations it is orders of magnitude faster than sympy.

SymPy was instrumental to my PhD implementation, mainly for simplifying math expressions. Nothing was even close at the time

https://github.com/verdverm/pypge

Unfortunately I always found it quite slow compared to Mathematica

That's a known problem and somewhat mitigated by symengine:

https://github.com/symengine/symengine

It's pure Python, so you can run it under PyPy.

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.

Super useful package. I hate working out maths by hand so I usually use it whenever possible.

I used this to calculate answers for calculus worksheets in LaTeX format in grad school.

Sympy is amazing, but i kinda fail to see whats news about it as its oldest commit is 14 years ago.

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.

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

Oldest commit was from today: https://github.com/sympy/sympy

Where are you getting 14 years from?

That's the youngest commit.

Some say Potato others say Tomato it's a british vs. american thing

That's the newest commit. The oldest commit on GitHub is from 2007: https://github.com/sympy/sympy/commit/99b21ff58ad2e2ba831725...

You wouldn’t say “my oldest child was born today” in reference to your family of six children born between 2008 and today though.

Reply on news.ycombinator.com