Replies: 3 comments 2 replies
-
I can help a little with this. I wonder how easy it would be to make this work in general though since SymPy routines generally make use of all kinds of Python features like keyword arguments, You would probably want to have an interface that resembles the way the code would be written if using SymPy directly e.g. maybe just something that uses EvalSymPy[ToSymPy[freeterm], ".evalf(chop=True)"] Of course there then needs to be something that can represent the return values of these operations which wouldn't necessarily be SymPy expressions (e.g. a set, dict, etc could be returned). Presumably there should also be some kind of There are some cases like |
Beta Was this translation helpful? Give feedback.
-
We will see, but I think wrapping existing sympy routines that do not have close WL primitives can be wrapped into Mathics functions outside of Mathics-core as a separate Pymathics module. See the Github Mathics3 project list for other Pymathics modules. However things like adding an apply rule for ReplaceAll ( |
Beta Was this translation helpful? Give feedback.
-
I just did some timings between calculating this in Mathics versus SymPy native: The comparison table first:
Mathics m = mmatera's run Now here is the actual run: $ IPython
Python 3.8.12 (default, Oct 21 2021, 14:26:19)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.29.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: from mathics.session import MathicsSession
In [2]: from mathics.core.expression import Expression
In [3]: from mathics.core.atoms import Integer
In [4]: expr1="poly = x^100000 + 1234 x^77777 - 2121 x^12345 + 7890 x^999 - x^11"
In [5]: expr2="freeterm = poly /. x -> 1234567;"
In [7]: session = MathicsSession()
In [8]: %time res1=session.evaluate(expr1)
CPU times: user 5.92 ms, sys: 885 µs, total: 6.8 ms
Wall time: 6.76 ms
In [9]: %time res2=session.evaluate(expr2)
CPU times: user 18.8 ms, sys: 0 ns, total: 18.8 ms
Wall time: 18.9 ms
In [10]: %time res3=session.evaluate("freeterm")
CPU times: user 137 µs, sys: 0 ns, total: 137 µs
Wall time: 140 µs
In [11]: %time val=res3.value
CPU times: user 3 µs, sys: 2 µs, total: 5 µs
Wall time: 6.68 µs
In [12]: %time len(str(val))
%time len(str(val)))
CPU times: user 5.03 s, sys: 8.18 ms, total: 5.04 s
Wall time: 5.03 s
Out[13]: 609152
In [13]: %time session.evaluate("N[freeterm]")
CPU times: user 6.93 s, sys: 10.2 ms, total: 6.94 s
Wall time: 6.94 s
Out[12]: <Real: 2.9269049981273425672557446655906860797274927961244575e+609151>
In [14]: from sympy import *
In [15]: x, y, z, t = symbols('x y z t')
In [16]: time poly = x**100000 + 1234* x**77777 - 2121* x**12345 + 7890* x**999 - x**11
CPU times: user 1.77 ms, sys: 0 ns, total: 1.77 ms
Wall time: 1.78 ms
In [17]: %time poly = x**100000 + 1234* x**77777 - 2121* x**12345 + 7890* x**999 - x**11
CPU times: user 150 µs, sys: 21 µs, total: 171 µs
Wall time: 177 µs
In [18]: %time freeterm = poly.subs(x, 1234567)
CPU times: user 2.41 ms, sys: 329 µs, total: 2.74 ms
Wall time: 2.75 ms
In [19]: %time N(freeterm)
CPU times: user 67 µs, sys: 9 µs, total: 76 µs
Wall time: 79.6 µs
Out[20]: 2.92690499812734e+609151
In [20]: type(res3)
Out[20]: mathics.core.atoms.Integer
In [21]: type(freeterm)
Out[21]: sympy.core.numbers.Integer |
Beta Was this translation helpful? Give feedback.
-
Table of Contents
Background
In #104 I brought up the idea of saving Expressions as their SymPy equivalent when that is possible.
It comes up in #103 where this sympy code is suggested:
While it turns out that in this particular case we can probably just fix Mathics code, as in #106 , I still see benefit from allowing users who are familiar with Sympy to have more access and control of its use directly, while still being able to make use of features that Mathics offers.
A Mathics SymPy Object
Just as we have an object for
DateTime
would could have an object for SymPy.So instead of:
One might imagine:
./
on a Sympy object would assumed to be.subs()
as used in the issue.Potential benefits
It gives users more direct access to Sympy and promoting better Sympy Mathics interaction I think is a good thing. (I also feel the same way about scikit, numpy, mpmath, and Jupyter).
It allows prototyping from the user side different ways to implement WL operations. These in turn could be made more permanent inside the core implementation.
Although it deviates from WL, I think that's okay because it distinguishes Mathics in a way might provide a benefit that is not likely to ever be available in WL. Strengthening the connections with other open-source projects is a good idea
Caveat
Although others are free to do what they like, personally, I would not consider undertaking this without a partner on the Sympy side who knows and understands that aspect well.
@oscarbenjamin is this something you would have time to help on? Of course, you'd need to set up a mathics-core development environment.
Beta Was this translation helpful? Give feedback.
All reactions