#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 burcin):
Thank you all for working on this again. I hope this will also solve some
of the long standing issues we had with the maxima interface, like setting
domains for variables #6862, or recognizing special symbols #6882.
Replying to [comment:40 nbruin]:
> > two return statements is indeed strange. Is the second return ever
reached?
>
> No, it isn't. However, Burcin apparently thought that {{{l.sage()}}}
would give better results. I'm actually thankful that he left in the
original return statement because that served as a nice flag that
something had changed there.
It was clearly a mistake on my part to leave the second return statement.
I'm glad it ended up being useful though.
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?
> > Could it be a left over forgotten there? Looking at the code I am not
sure
> > what ex.parent()(l) is supposed to be.
>
> It is "Coerce l into the parent of ex", the original input parameter,
i.e., coerce l into the Symbolic Ring. In the new code, "sr_limit"
produces something that is hopefully *coercible* into the SymbolicRing --
it probably isn't a maxima object at all anymore. I think in all cases
it's better to coerce into SR instead of calling l.sage(): On maxima
objects it should be about the same and if limit produces something that
cannot be represented in the SymbolicRing we should get an error. I'll
ping him about it.
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.
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. The code for this function is
simply
{{{
def _sage_(self):
import sage.calculus.calculus as calculus
return calculus.symbolic_expression_from_maxima_string(self.name(),
maxima=self.parent())
}}}
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.
I am not quite sure what a conversion to the symbolic ring does for maxima
interface objects. I don't expect it to have special behavior if the input
is a maxima interface object. It would make sense, if it called the
.sage() or ._sage_() methods of the argument though.
Sorry I can't be more helpful.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7377#comment:43>
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.
