#16594: symbolic_expression_from_maxima_string() much too slow
-------------------------------------------------+-------------------------
Reporter: rws | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.3
Component: interfaces | Resolution:
Keywords: maxima, conversion, | Merged in:
optimization, speed | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | Stopgaps:
Dependencies: |
-------------------------------------------------+-------------------------
Comment (by nbruin):
First a technicality (which I don't think affects the point you're
making): You're feeding `sefms` a string that's not coming from maxima, so
it's not entirely obvious that `str(ex)` is valid input for `sefms`. For
instance:
{{{
sage: maxima_calculus(euler_gamma)
%gamma
sage: maxima_calculus(pi)
%pi
}}}
so `sefms` is getting all kinds of symbols here that in maxima don't
represent what they're meant to.
In fact, if I try to convert properly, I get an error for this expression:
{{{
sage: maxima_calculus(ex)
TypeError: ECL says: Error executing code in Maxima: expt: undefined: 0 to
a negative exponent.
}}}
The same problem arises when we try to avoid string manipulations as much
as possible:
{{{
sage: t=maxima_calculus(str(ex))
sage: from sage.interfaces.maxima_lib import max_to_sr
sage: %time max_to_sr(t.ecl())
CPU times: user 1.6 s, sys: 3 ms, total: 1.6 s
}}}
Indeed, the fact that these expressions aren't valid prevents us from
checking that the results are equal:
{{{
sage: bool(max_to_sr(t.ecl()) == sefms(str(ex)))
TypeError: ECL says: Error executing code in Maxima: expt: undefined: 0 to
a negative exponent.
}}}
I think the case would be better made with an example that's actually
valid.
That said, I suspect the following happens: when we reconstruct an
expression (from a string or otherwise), we ''call'' the symbolic
functions in question, relying on them producing an appropriate symbolic
expression. However, many symbolic functions try to do some
simplifications before giving up and just returning a symbolic expression.
As you're experiencing, some of these routines may be trying a little
much for cases where, given the source of the expression, we expect very
little simplification to occur.
Bypassing this, however, would be rather complicated. Of course, we could
just transliterate the syntax trees (in essence, the other direction
`sr_to_max` does that--it does NOT call the maxima translations but just
puts their symbols in an expression tree) but in reality we don't have the
information for doing so. It would also mean that the current
decentralized architecture where every symbolic function gets a chance to
validate its arguments would need to be revisited.
The most reasonable solution might be to equip all symbolic function-
producing call sequences (or at least the ones that interfaces produce)
have an extra optional argument `dont_do_anything_fancy=True`, to avoid
any expensive argument manipulations. Perhaps this can be coordinated with
`hold=True` which already exists on some.
You would then have to insert that optional parameter at all relevant
spots.
In short: it's not `sefms` itself, it's the fact that `sefms` is accessing
sage's symbolic functions via their end-user interface, because we don't
have another one.
--
Ticket URL: <http://trac.sagemath.org/ticket/16594#comment:1>
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.
