#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 | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
---------------------------+------------------------------------------------
Comment(by nbruin):
Replying to [comment:24 jpflori]:
Hi Jean-Pierre,
It's great you're taking on this project! It has the potential of being a
lot of fun. I won't be working on it, so I'm very happy to see someone
else interested in taking it on. I'll give you some background on the
points you raise, so that you can take more informed design decisions.
> I think some refactoring still has to be done for the new classes. The
abstract class is a good idea to transparently switch interface but I
think it would be cleaner if it did not inherit from Expect class (and so
"Maxima as a lib" does not too). I'll try to work on this this weekend.
The *only* reason to organize the maxima interfaces as they are now is
because Robert remarked that whatever was needed to communicate with
maxlib at a string-level was going to have a lot of overlap with the
present maxima interface. Hence, he abstracted out the common stuff and I
modified the concrete maxlib interface to talk to ecllib instead of a
separate process. This was experimental and at the time I had no idea how
much was necessary, so I changed as little as possible: The original
interface inherited from expect, so the new one did too, just overriding
whatever methods needed overriding. So yes, there will be a lot of lint
and extraneous stuff in there. What you're looking at is a first hack.
> It should be also be decided, which interface is used for what,
especially since we can only have one "Maxima as a lib" running. Should
that Maxima as lib be used for calculus and be given a direct access
(maybe as "maximalib" variable as "maxima" gives access to a copy of
Maxima in Sage, even if currently the "maxima" variable points to a
different instance of Maxima than the one used by calculus).
The largest benefit is to be gained when the communication can avoid
string parsing altogether. (ecllib at the moment converts Integers to ecl
bignums via strings, which is silly: They are both implemented as gmp/mpir
integers! The only reason is that I never succeeded in importing the
gmp/mpir headers in a usable way in ecl.pyx, to copy over the integer. ECL
largely avoids gmp's registered memory manager, so some care must be taken
to transfer the integer to properly allocated memory.) The routines
sr_to_max and max_to_sr (in the fastcalculus patch) implement this
strategy. If you want to have this benefit, the maxlib instance *has* to
be the "calculus" instance. Note that the default "maxima" instance is
already distinct from the "calculus" instance:
{{{
sage: integrate(cos(x),x);
sage: maxima(x);
sage:
Exiting Sage (CPU time 0m0.12s, Wall time 0m16.73s).
Exiting spawned Maxima process.
Exiting spawned Maxima process.
}}}
(note the two maxima spawns)
Once the design has stabilized, it would be possible to make max_to_sr and
sr_to_max more intelligent. For instance, SR variables would not need to
be translated to maxima identifiers with the same name. This currently
leads to problems, because this conversion collapses namespaces:
{{{
sage: cosvar=SR.var("cos")
sage: cos(cosvar)
cos(cos)
sage: integrate(cos(cosvar),cosvar)
integrate(cos(cos), cos)
sage: cosvar=SR.var("sage_cos")
sage: integrate(cos(cosvar),cosvar)
sin(sage_cos)
}}}
as you see, the print name of the SR.var matters!
Let me know if you have further questions. I might be able to help with
information.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7377#comment:25>
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.
