by carapace on 9/8/23, 3:22 PM
by mathisfun123 on 9/8/23, 2:43 PM
The unfortunate thing is that core CAS functionality (and performance) should be based on a SAT/SMT engine to discover the rewrite rules and it goes without saying (but I'll say it anyway) implementing that is "hard". Naively (i.e., I haven't
really thought through it), I think sympy should be built on top of z3 or cvc5 or at least very tighly integrated (e.g., support as a backend). And (again naively) I think until such time, sympy will remain a toy.
I will say though that symengine is a great project and congrats to that guy for pulling it off under the constraints of a phd.
by 7thaccount on 9/8/23, 3:18 PM
I really liked the article and how it explained CAS vs Numerical solutions.
It also looks like SymPy or SymEngine is starting to catch up to Mathematica which also is pretty cool and does the same kind of expansion of an expression into a tree of sub expressions.
by eigenket on 9/8/23, 2:37 PM
I love SymPy. Its so useful for doing calculations I don't want to do myself.
by qubex on 9/8/23, 6:41 PM
I’ve tried to appreciate SymPy but I always find myself running home to Mathematica. There’s simply no comparison. SymPy is like a match and Mathematica has the power of a sizeable thermonuclear warhead.
by bionhoward on 9/8/23, 6:43 PM
If you have fewer primitives and terminals than there are UTF-8 characters (1.1 million), then you could ditch OOP expression trees altogether and use simple strings in Polish notation with a mapping of utf-8 characters to operations (simple lambdas). That way you don’t need __dict__ on every node of every tree. However, you’d have to rewrite the stuff which expects the OOP trees to instead expect Polish notation strings. This approach scales a lot further than classes because you reduce the memory cost of the algebraic expressions down to the simplest string to represent them (and even smaller if you pack the bits into an ANS, that’s a performance hit to reduce memory more)
by haberman on 9/9/23, 12:15 AM
I remember being a kid and fawning over the upgrade from a TI-86 (which could not do symbolic manipulation) to the TI-89 (which could).
As an adult and OSS enthusiast, I've often wondered if there is an OSS option that can at least match, and ideally exceed, the TI-89's capabilities. Is SymPy it? I've had a few reasonably good experiences with SymPy, but I don't know much about the theoretical underpinnings of CAS, or how SymPy compares to competing offerings.
by HelloNurse on 9/8/23, 4:13 PM
Regarding the issue of representing symbolic expression and controlling their evaluation or simplification, are there precedents of using e-graphs to memoize and reuse work rather than simple trees with destructive updates?
by roger_ on 9/8/23, 3:37 PM
SymPy is pretty nice but every time I use it for a real problem I end up hitting a wall and have to dig through the source or look at old issue reports for a workaround.
Most recently I wanted to simplify a complex expression with terms like ‘diag(v1) * v2’ into Hadamard products, and found I’d need to implement custom rules to get it to work.
by amelius on 9/8/23, 8:28 PM
Python is great in DL, so any chance we'll see a combination of neural nets and computer algebra in a new sympy?
by j2kun on 9/8/23, 9:18 PM
If the author is reading this: please add an rss feed to the blog! I'd love to follow along for updates
by kzrdude on 9/8/23, 4:37 PM
I think banking on SymEngineX ("SEX") for the Sympy 2.0 release would be interesting branding.
I'm also cheering for Sympy, I think it's longevity now still predicts success in the future.