Replies: 3 comments 1 reply
-
|
From my point of view, Mathics should not be a WL interface for Sympy, but just the opposite: Sympy would be another library to implement evaluations when there is not a native implementation. So, I like the idea go forward with decoupling Sympy from the core. |
Beta Was this translation helpful? Give feedback.
-
It is a bit of work to do. And we haven't finished decoupling loading individual Builtins from module importing. (I realize now if that had been done sooner, we would have had a more seamless way of handling the network/graph and natural language modules. And that can still be done in the future.) |
Beta Was this translation helpful? Give feedback.
-
|
Sure, it is not something to solve right now, but at least defines a direction. |
Beta Was this translation helpful? Give feedback.
-
|
For those that want to benchmark stuff now to see what improvement we might get using symengine.py see https://groups.google.com/g/sympy/c/ZSG1Rl5MVRs?pli=1 |
Beta Was this translation helpful? Give feedback.
-
See https://github.com/symengine/symengine
I have trepidation though in mentioning this because I believe most of Mathics problems are still gross inefficiencies in how it organizes the computation - still doing too many costly conversions, especially where large data is involved, not being able to turn expressions into instructions which can be "optimized" in larger chunks and so on.
Right now, Sympy vs mpmath is done via OO-ness, and that means that both of these are required as a dependency of mathics-core. Splitting the OO behavior would make it easier to split off a computation backend as an external module.
Beta Was this translation helpful? Give feedback.
All reactions