#12796: Allow more general evaluation of FDerivativeOperator
-------------------------------+--------------------------------------------
Reporter: nbruin | Owner: burcin
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.0
Component: symbolics | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Nils Bruin | Merged in:
Dependencies: | Stopgaps:
-------------------------------+--------------------------------------------
Comment (by nbruin):
Replying to [comment:11 mjo]:
> > > * Logic duplicated in `max_at_to_sage()` and `calculus.at()`
> >
> > Don't import `sage.calculus` into `maxima_lib`, because the reverse
import is already in effect. I don't think a bit of logic duplication here
is so problematic, since the input the routines in maxima_lib have to deal
with is much better controlled than the other ones. `maxima_lib` has the
potential for much better optimizations. So perhaps leaving it as it was
is simplest and acceptable?
> [[BR]]
> We're doing a lazy_import of maxima_lib in calculus, though, or is there
still a reason to avoid it? I'll just revert that too if so.
I know I had trouble with it before, with dummy_integral. You're right
that the lazy import might have fixed the issue there.
My main argument against sharing the code would be to keep the logic
simple. The routines `symbolic_expression_from_maxima_string` and
`max_to_sr` both serve to translate maxima expressions to SR expressions
and they do so independently by design (ideally, we can eventually rip out
the entire string-based conversion). In this case we're finding that both
need to translate `at` to a `subs` method call. In both cases, the
translation is straightforward. If you find that the translation step is
too involved to replicate, the proper place to fix it would be to add, for
instance, an "at" method to SR that accepts input closer to what
`symbolic_expression_from_maxima_string` and `max_to_sr` find. I don't
think that's necessary (and it's nicer to keep SR as lean as possible).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12796#comment:12>
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.
