Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SymPy: Symbolic Mathematics in Python

sympy.org

Post reply on HN
Print view View original

111–120 of 137 posts

Re: SymPy: Symbolic Mathematics in Python

#111

Post by cashsterling »

Ginger-Pickles wrote: post #81
mbustamanter wrote: post #40

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

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

MathCad works this way also, IIRC.

Re: SymPy: Symbolic Mathematics in Python

#112

Post by wakawaka28 »

taeric wrote: post #110
in9 wrote: post #107

Earlier quoted context omitted.

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…

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.

Re: SymPy: Symbolic Mathematics in Python

#113

Post by wakawaka28 »

Affric wrote: post #106
pquki4 wrote: post #82

Earlier quoted context omitted.

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…

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.

Re: SymPy: Symbolic Mathematics in Python

#114

Post by wakawaka28 »

Qem wrote: post #96
WoahNoun wrote: post #67

Earlier quoted context omitted.

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.

Re: SymPy: Symbolic Mathematics in Python

#115

Post by bmitc »

in9 wrote: post #107
bmitc wrote: post #93

Earlier quoted context omitted.

> 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

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

Re: SymPy: Symbolic Mathematics in Python

#116

Post by bmitc »

wakawaka28 wrote: post #112
taeric wrote: post #110

Earlier quoted context omitted.

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…

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.

Re: SymPy: Symbolic Mathematics in Python

#117

Post by taeric »

wakawaka28 wrote: post #112
taeric wrote: post #110

Earlier quoted context omitted.

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…

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.

Re: SymPy: Symbolic Mathematics in Python

#118

Post by Affric »

wakawaka28 wrote: post #113
Affric wrote: post #106

Earlier quoted context omitted.

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.

Re: SymPy: Symbolic Mathematics in Python

#119

Post by tonyarkles »

mattivc wrote: post #20
abricq wrote: 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…

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.

Re: SymPy: Symbolic Mathematics in Python

#120

Post by nephanth »

fho wrote: post #83
abricq wrote: 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…

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

Numba would probably do the job too
Post reply on HN