Opened 7 years ago
Last modified 6 years ago
#16594 new defect
symbolic_expression_from_maxima_string() much too slow
Reported by: | rws | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-6.4 |
Component: | interfaces | Keywords: | maxima, conversion, optimization, speed |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string as sefms sage: var('v1,v2,v3') (v1, v2, v3) sage: ex=-1/3*(pi + 1)*(3*(euler_gamma - e)*(pi - 3*v1 - v1/arcsech(1) + e^(-1)/pi) - 6*v3^2*arcsinh(-v1 + e)/v2 - v2 - 3*log_gamma(v1*v3)/v2 - 3*e^(-254) + 3)*(-catalan/v3)^(twinprime*pi - 1/2*v1 - 1/2*v2)*inverse_jacobi_cs(1, v3)/jacobi_sc(1/arccos(-1/(v1*csc(v3))), v3/v1 + e) - 1/4*(2*v3^2*(e + 1) + ((e*log_integral(arcsech(exp_integral_e1(v2^mertens - 1) - 4)) + 15*v1 + jacobi_dn(v2, pi))*v1*e^(-1) + golden_ratio*pi^v1*(1/v3^12 + jacobi_ds(-10, csc(v3^2)))^(v2 - 1/2/v2)*sinh(v2*e)/((v1 + v2 + v3 + 1)*v2))/(v1^2*inverse_jacobi_nc(v1, -e)) - 2*bessel_Y(v3, v2))/v2 + v3/inverse_jacobi_sc(1, v2) - (v1 + 1)/((v2 + v3)*(2*(v1 + e)*(v3 - 1)/(pi + v1) + (-v3*sech(v1*v3)/v2)^(-e/v1))) + inverse_jacobi_cn(pi + v1*v3, pi - v3) + jacobi_sn(e, arctanh(-(-log_integral(2) + log_integral(jacobi_ds(-1, v3)))^v2*e)^(1/7*(18*v2 - v3)*(14*v2 + e)/(v3*arctan(1/v2)*kronecker_delta(v1, v3)))) sage: timeit('sefms(str(ex))') 5 loops, best of 3: 2.19/2.14/2.15 s per loop (without #6882) 5 loops, best of 3: 2.13/2.11/2.12 s per loop (with #6882)
It calls 120 times the function MaximaLib._eval_line()
which takes 17ms in average = 2 seconds. 17 ms is an eternity. A lot of simplification attempts are going on in _eval_line
. For this expression I count ten calls to trigsimp
, trigexpand
, radcan
, fullratsimp
. Why would we want to call Maxima when converting *from Maxima, at all? And if it's necessary to build the expression, why simplify when it's supposed to be already simplified?
Change History (2)
comment:1 Changed 7 years ago by
comment:2 Changed 6 years ago by
- Milestone changed from sage-6.3 to sage-6.4
Note: See
TracTickets for help on using
tickets.
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 thatstr(ex)
is valid input forsefms
. For instance: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:The same problem arises when we try to avoid string manipulations as much as possible:
Indeed, the fact that these expressions aren't valid prevents us from checking that the results are equal:
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 withhold=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 thatsefms
is accessing sage's symbolic functions via their end-user interface, because we don't have another one.