|
|
|
|
|
by bocklund
2166 days ago
|
|
Even though SymPy is written in Python, there are several options to go much faster. The simplest is when actually using the symbolic expression to do some calculation. For that SymPy has a `lambdify`, which can make a callable using NumPy as the backend. They also have a variety of code printers to write your expression in C/Fortran/Julia/<many others> that you can compile to be very fast. There’s also the SymEngine project, which is a rewrite of SymPy in C++ with bindings to other languages (like Python where it is a drop-in API replacement for SymPy). It’s not finished yet, but the CAS is a lot faster and it’s lambdify can give you an internal representation or an LLVM-compiled version, both of which are much faster than SymPy in compile-time and run-time for our expressions (which are often quite large, but simple in terms of the mathematical functions used). |
|
Yeah, SymEngine is a great idea and it is a lot faster, but its functionality is very limited compared to SymPy. The development is slower than SymPy and I suppose its due to the fact that its in C++, which is more difficult to write after all. Therefore I don't believe it will ever catch up with SymPy features and it boils down to the two-language problem. I think Julia (with multiple dispatch, parametric type system and JIT) is a great candidate for CAS, but it's still very far behind SymPy (although the nice thing is that functionalities can be "borrowed" via PyCall until they are rewritten).