-
-
Notifications
You must be signed in to change notification settings - Fork 523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
speed up Maxima computations by using more of maxima_calculus.eval() #30071
Comments
This comment has been minimized.
This comment has been minimized.
comment:2
I really want to understand why I can't seem to find the code responsible for this, though. |
comment:3
Testing on macOS, I get
|
This comment has been minimized.
This comment has been minimized.
comment:4
Replying to @mkoeppe:
right, I probably did something wrong here. Indeed, on Linux I get similar timings. |
comment:5
still there is something funny going on
If I remove |
comment:6
Replying to @dimpase:
I think this example is showing that maxima's string parser is faster than our to/from binary data conversion for ecllib. I can believe that: there's still a lot of work and memory allocation to do to translate python objects to lisp objects and back. I can imagine that parsing such a small string is easier (the construction of the lisp float objects etc. needs to happen in both cases, so it's really just parsing against the python object constructions). You could try and profile the code to see if anything bad is happening. For the results via the expect interface: since the python-to-maxima translation now needs to happen through parsing anyway, it's bound to be slower: there's no upside compared to the "eval" at all. The fact that it actually times out: I'd suspect there's an io buffer that gets flooded or an expect interface that gets out of sync due to the high data flow. Note that the timeout happens in the expect interface. |
comment:7
In src/sage/calculus/calculus.py one reads The symbolic calculus package uses its own copy of Maxima for
simplification, etc., which is separate from the default
system-wide version::
sage: maxima.eval('[x,y]: [1,2]')
'[1,2]'
sage: maxima.eval('expand((x+y)^3)')
'27'
If the copy of maxima used by the symbolic calculus package were
the same as the default one, then the following would return 27,
which would be very confusing indeed!
::
sage: x, y = var('x,y')
sage: expand((x+y)^3)
x^3 + 3*x^2*y + 3*x*y^2 + y^3 Is this the only issue (variable binding in SR done via |
comment:8
Note that at least in some modules, actually |
comment:10
Also the code of Let's make a list... Outside of doctests, I see:
Anything else? |
comment:11
in src/doc - the example in the ticket description is from there |
comment:13
Setting new milestone based on a cursory review of ticket status, priority, and last modification date. |
Empirically,
maxima_calculus.eval()
is 5-7 times faster thanmaxima.eval()
, cf. e.g.For some reason, there are dozens of
maxima.eval
calls in sage/[src,doc] - and none ofmaxima_calculus.eval
. Just going and changing these will be an improvement (in particular, on Cygwin, where pexpect is very flaky, cf #22191).maxima.jacobi_sn()
is also much slower thanmaxima_calculus.jacobi_sn()
This should be a part of #17753.
CC: @nbruin @rwst @kcrisman
Component: interfaces
Issue created by migration from https://trac.sagemath.org/ticket/30071
The text was updated successfully, but these errors were encountered: