#7377: Symbolic Ring to Maxima via EclObject
-----------------------------------------------------------------------+----
Reporter: nbruin |
Owner: nbruin
Type: enhancement |
Status: needs_work
Priority: major |
Milestone: sage-feature
Component: symbolics |
Keywords:
Author: Nils Bruin, Jean-Pierre Flori |
Upstream: N/A
Reviewer: Jean-Pierre Flori, François Bissey, Karl-Dieter Crisman |
Merged:
Work_issues: |
-----------------------------------------------------------------------+----
Comment(by nbruin):
Thank you, Burcin. That is very useful information indeed.
> I don't have much time these days to investigate this. So it would be
great if someone can update me on the progress. Especially, when rebasing
Robert's patch to split off the maxima interface, did you merge in the
changes that were made to sage/interfaces/maxima.py in the meantime?
I'll leave that to JP
> The operation we are using is conversion, not coercion. IMHO, the code
for converting maxima objects (of any kind, pexpect or library) to Sage
symbolics objects should be within the maxima objects. Most of this
functionality is in sage/calculus/calculus.py at the moment, I would like
to see that moved to sage/interfaces/maxima.py or it's variants.
OK, conversion indeed. Good to know there is a philosophy behind the
change
> Adding a .sage() method to maxima interface objects was a step in this
direction. This method knows which lookup tables to use to convert
functions, etc. from maxima back to Sage.
Ultimately, this model might fit better with maximalib, but currently it
means some refactoring of what we already had (or just go back to the SR
coercion)
> around line 1775 of sage/interfaces/maxima.py. I would expect this to
work for the library interface to maxima as well, since AFAIK, this is
also string based ATM.
With the fastcalculus patch it is not, though. In principle one could try
to polish the abstract_maxima and maxima_lib patches so that they give a
drop-in string-based library interface to maxima, but I never really went
that far. That would be (probably boring but) very well-defined project
and might speed up adoption.
What happens with the current set of patches:
* a maxima_lib interface is made available that in principle should be a
drop-in replacement for maxima (except that only one instance can exist)
* this interface adds some extra methods to get "under the hood" of
objects:
(1) There is an .ecl() method that returns the underlying EclObject
(i.e., direct access to the LISP object implementing the maxima object)
(2) the maxima() method also accepts EclObjects and returns the
appropriate wrapper, so maxima(M.ecl()) and maxima(eclobject).ecl() are
supposed to be the identity (In a strong sense: The python wrapped might
change Id but the ecl object not) where defined.
(3) sr_to_max(), a method to translate an SR object into an EclObject
ready for wrapping in maxima.
(4) max_to_sr(), a method to translate an EclObject representing a
maxima expression to something in or coercible to SR. Note that maxima
expressions can be lists, which should be translated into a python list of
SR elements, so the mapping cannot be perfectly into SR.
(5) methods sr_limit, sr_sum, sr_integrate which expect arguments
living in SR and return something convertible to SR
The idea is that (3) and (4) offer a way to go back and forth between SR
and maxima without using strings. maxima(E) and maxima(sr_to_max(E))
should have the same result. Similarly, SR(M) and SR(max_to_sr(M.ecl()))
should have the similar result. Under the hood, sr_to_max and max_to_sr
keep mappings between SR symbols and their EclObject counterparts. They
build up these mappings via the string-based interface, but avoid strings
once they know the mappings.
The methods in (5) were an attempt to make "compute limit/sum/integral via
maxima" dependent on which maxima interface was in use. The old maxima-
interface got stubs that just returned the result of calling the
appropriate maxima expression, which returns a maxima expression, which is
coercible into SR again.
The maxima-lib implementation uses sr_to_max and max_to_sr as much as
possible and returns the result of a max_to_sr, so that should be
coercible into SR as well.
Doing it this way (at the time) was the smallest change and left as much
as possible in the calculus.limit routine. The general setup fits will in
Burcin's philosophy, but is presently broken because the result of a
max_to_sr likely doesn't have a .sage() method. An alternative would be to
push the actual conversion of the answer to SR into the sr_limit routine
as well. But then one would have to tell sr_limit into which SR the answer
has to be pushed. (I guess expr.parent())
I think the _proper_ way to do all these computations is to construct a
dummy_limit or a dummy_integral in SR first ("inert" limit and "inert"
integral being the less opinionated synonyms), convert that to maxima (via
sr_to_max or string-based), call the appropriate simplification on it
there (note that sr_to_max will absolutely not do any simplification. It's
just mapping over expression trees) and then pull the answer back via
max_to_sr or string based.
To come up with a truly robust design for this (the present was just a
first hack and proof-of-concept), people who know a lot about SR and the
general calculus architecture need to be involved. I've tried to show with
various examples on this ticket that you don't need to understand much of
lisp to make sense of what happens in maxima. The sage side of this is
really much more complicated than the maxima side. The ECL objects
representing maxima expressions look messy and have a lot of parentheses,
but have a very straightforward structure.
Finally for (4): I know maxima functions like li[n] and psi[n] are not
translated yet, because recognising them means looking a bit deeper in the
maxima constructs. This is straightforward to do. There may be more of
these constructs. Whoever wrote the string-based converter probably knows
them already, because there they need special treatment too.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7377#comment:44>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
