#18920: upgrade Maxima to 5.36.1
-------------------------------------+-------------------------------------
Reporter: dimpase | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.8
Component: symbolics | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/dimpase/eclupdate | 0d0649ad925808a308084b04253d7eb5c3fe2fad
Dependencies: #18961 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:34 dimpase]:
> They say the change is a
[http://sourceforge.net/p/maxima/bugs/2998/#09b6 by-product to fix another
bug]. Obviously it is a low priority for them to make the output backwards
compatible. I wonder if we should just fully switch to `maxima_lib.py` and
do not try to deal with this in some other way?
Robert isn't making any statement there about priority. I would not think
it's a very low priority, because the current behaviour is tantamount to
writing `(sin)(x)`, which is silly. I would not be surprised if in the
next couple of weeks, when he has had a chance to think about a solution,
he will have a fix. I'm sure it's not hard to fix. It just needs some
thought to fix it properly and efficiently.
In terms of total amount of work, I would think introducing "curried"
poylog and psi will be less work than eliminating any dependence on string
parsing from maxima.
For calculus use, we're already moved entirely to maxima_lib. The library
instance just allows two interfaces back and forth: a strings-based one
and the binary `sr_to_max` and `max_to_sr` one.
Moving calculus entirely to `sr_to_max` is a nice idea in general, and
that's a worthwhile project that should be quite doable (we're halfway
there already and it didn't take much work to do that).
It would mean identifying all remaining places where calculus triggers
string conversions and replace those sites with mechanisms comparable to
sr_integral, sr_limit, sr_sum etc.
I think it's worthwhile if somehow we do maintain the pexpect interface to
maxima as well, even if we don't need it for the calculus functionality in
sage proper (and since the strings-based interface in maxima_lib shares
nearly all its code with that, we might as well keep that too). Having the
pexpect interfaces in sage is a useful feature for communicating with
other computer algebra systems.
--
Ticket URL: <http://trac.sagemath.org/ticket/18920#comment:35>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
