Live data from Hacker News

SymPy: Symbolic Mathematics in Python

sympy.org

121–130 of 137 posts

Re: SymPy: Symbolic Mathematics in Python

#121
post #118

Earlier quoted context omitted.

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

Re: SymPy: Symbolic Mathematics in Python

#122
post #117

Earlier quoted context omitted.

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.

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.

Re: SymPy: Symbolic Mathematics in Python

#123
post #116

Earlier quoted context omitted.

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.

Re: SymPy: Symbolic Mathematics in Python

#124
post #118

Earlier quoted context omitted.

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 monolith…

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.

Re: SymPy: Symbolic Mathematics in Python

#125
post #93

Earlier quoted context omitted.

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?

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!

Re: SymPy: Symbolic Mathematics in Python

#127
post #82
post #46

Earlier quoted context omitted.

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

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…

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.

Re: SymPy: Symbolic Mathematics in Python

#128
post #93

Earlier quoted context omitted.

> SymPy is open source, mathematica is not. Why does that matter?

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 e…

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

Re: SymPy: Symbolic Mathematics in Python

#129
post #117

Earlier quoted context omitted.

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

Re: SymPy: Symbolic Mathematics in Python

#130
post #11

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, immediat…

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