#18920: upgrade Maxima and ECL to 5.36.0.1 and 15.3.7, respectively
-------------------------------------+-------------------------------------
Reporter: dimpase | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.8
Component: symbolics | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/dimpase/eclupdate | 82fdf0eaa092b63cc98d97b418721795ea6b5081
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:23 dimpase]:
> {{{
> TypeError: unable to make sense of Maxima expression
'(1/432)*(72*gamma(1/3)*(psi[2])(1/3)+((-72)*euler_gamma^3+((-36)*pi*3^(1/2)+(-324)*log(3))*euler_gamma^2+((-108)*log(3)*pi*3^(1/2)+(-18)*pi^2+(-486)*log(3)^2+(-216)*(psi[1])(1/3))*euler_gamma+((-1)*pi^3+((-81)*log(3)^2+(-36)*(psi[1])(1/3))*pi)*3^(1/2)+(-27)*log(3)*pi^2+(-243)*log(3)^3+(-324)*(psi[1])(1/3)*log(3))*gamma(1/3))*_SAGE_VAR_x^3+(1/24)*((12*euler_gamma^2+(4*pi*3^(1/2)+36*log(3))*euler_gamma+6*log(3)*pi*3^(1/2)+pi^2+27*log(3)^2+12*(psi[1])(1/3))*gamma(1/3))*_SAGE_VAR_x^2+((-1)/6)*((6*euler_gamma+pi*3^(1/2)+9*log(3))*gamma(1/3))*_SAGE_VAR_x+gamma(1/3)'
in Sage
> }}}
> and
> {{{
> TypeError: unable to make sense of Maxima expression
'8*(li[33])(e^u)+3*(li[2])(u)' in Sage
> }}}
No, it is not very easy to fix. We rewrite `li[n](` to `polylog(n,` and
the same for `psi[n](` to `psi(n,`. This string matching obviously
completely breaks if maxima starts spelling this as `(li[n])(x)`. Quite
frankly, that's an insane spelling, so perhaps the preferred approach is
to clarify with the maxima folks if they really intend this. It might be
an unforeseen byproduct of some other change that they prefer to fix
themselves, in which case we shouldn't waste time.
If they insist this is a reasonable spelling, I think we can work around
it, but it'll be a bit of real work. Note that we can handle calls to
parenthesized functions:
{{{
sage: from sage.calculus.calculus import
symbolic_expression_from_maxima_string as sefms
sage: sefms('(sin)(x)')
sin(x)
}}}
so as long as we ensure that expressions like `li[n]` and `psi[n]`
themselves get parsed to callable functions, we should be OK. Something
like this would be OK:
{{{
sage: sefms('li[n]')
curried_polylog(n)
sage: sefms('li[n]')(x)
polylog(n,x)
sage: sefms('(li[n])(x)')
polylog(n,x)
}}}
Since we cannot really handle square brackets, we'd need to do the
`li[n]`->`curried_polylog(n)` via a string substitution, but that should
be OK. The `curried_polylog(n)` would just create a symbolic function
that, when called with a single argument, would create the appropriate
polylog.
The binary conversion `sr_to_max` in `maxima_lib.py` shouldn't be
affected, unless they have changed their internal representation of
polylogarithms.
--
Ticket URL: <http://trac.sagemath.org/ticket/18920#comment:24>
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.
