#16732: Fix _maxima_init_evaled_ use, as well as translations of psi etc.
to/from
maxima.
-------------------------------------+-------------------------------------
Reporter: nbruin | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.3
Component: interfaces | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/nbruin/ticket/16732 | c28d9bdcb7ed0023f5eccb31d021207668259ee2
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Description changed by nbruin:
Old description:
> Follow-up to #9217. We have some imperfect translations to/from maxima of
> `psi(x,y)`. The template is:
> {{{
> sage: x,y=var("x y")
> sage: maxima_calculus(psi(x,y))
> psi[x](y)
> }}}
> The conversion doesn't seem to recurse on either argument, though:
> {{{
> sage: maxima_calculus(psi(psi(x,y),y))
> psi[psi(x,y)](y)
> sage: maxima_calculus(psi(x,psi(x,y)))
> psi[x](psi(x,y))
> }}}
> (note that the inner psi does not have the square brackets in either
> case.)
> Perhaps even worse:
> {{{
> sage: maxima_calculus(psi(x,polylog(3,x)))
> psi[x](polylog(3,x))
> sage: maxima_calculus(polylog(3,x))
> li[3](x)
> }}}
> As you see, the polylog doesn't get translated properly! This indicates
> misimplemented `_maxima_init_evaled_`, and probably those occur in
> several spots. Perhaps the way `_maxima_init_evaled_` gets called by the
> translator needs amendment? (the arguments need processing). The problem
> seems to occur in
> [http://git.sagemath.org/sage.git/tree/src/sage/functions/special.py#n502
> sage/functions/special.py line 502], where the arguments are apparently
> fed raw into `_maxima_init_evaled_` and where `_maxima_init_evaled_` is
> usually implemented as some basic string manipulation.
>
> Round-tripping only works for completely numeric first arguments (as per
> how the responsible regexp is designed):
> {{{
> sage: maxima_calculus(psi(x,y))._sage_()
> TypeError: unable to make sense of Maxima expression 'psi[x](y)' in Sage
> }}}
>
> These conversions all go fine with the tree-walking translation of
> maxima_lib (which gets used for some, but not all calculus operations):
> {{{
> sage: from sage.interfaces.maxima_lib import sr_to_max,max_to_sr
> sage: T=maxima_calculus(sr_to_max(psi(psi(x,y),y))); T
> psi[psi[x](y)](y)
> sage: max_to_sr(T.ecl())
> psi(psi(x, y), y)
> }}}
> Note that the regex-based "._sage_()" conversion will fundamentally have
> trouble with nested square brackets:
> {{{
> sage: T._sage_()
> TypeError: unable to make sense of Maxima expression 'psi[psi[x](y)](y)'
> in Sage
> }}}
> As a first step we might want to change the regex to accept "non-]"
> inside the square brackets to allow translation with non-numeric
> parameters. I don't think anybody has seen an expression in the wild yet
> that has nested square brackets (indeed, mostly the parameter is explicit
> numeric).
>
> There are some other maxima functions that use square brackets too. These
> might benefit from a similar treatment.
New description:
Follow-up to #9217. We have some imperfect translations to/from maxima of
`psi(x,y)`. The template is:
{{{
sage: x,y=var("x y")
sage: maxima_calculus(psi(x,y))
psi[x](y)
}}}
The conversion doesn't seem to recurse on either argument, though:
{{{
sage: maxima_calculus(psi(psi(x,y),y))
psi[psi(x,y)](y)
sage: maxima_calculus(psi(x,psi(x,y)))
psi[x](psi(x,y))
}}}
(note that the inner psi does not have the square brackets in either
case.)
Perhaps even worse:
{{{
sage: maxima_calculus(psi(x,polylog(3,x)))
psi[x](polylog(3,x))
sage: maxima_calculus(polylog(3,x))
li[3](x)
}}}
As you see, the polylog doesn't get translated properly! This indicates
misimplemented `_maxima_init_evaled_`, and probably those occur in several
spots. Perhaps the way `_maxima_init_evaled_` gets called by the
translator needs amendment? (the arguments need processing). The problem
seems to occur in
[http://git.sagemath.org/sage.git/tree/src/sage/symbolic/expression_conversions.py#n550
sage/symbolic/expression_conversion line 550], where the arguments are fed
raw into `_maxima_init_evaled_` (compare it to the cases below where the
operands do get passed through the interface) and where
`_maxima_init_evaled_` is usually implemented as some basic string
manipulation.
Round-tripping only works for completely numeric first arguments (as per
how the responsible regexp is designed):
{{{
sage: maxima_calculus(psi(x,y))._sage_()
TypeError: unable to make sense of Maxima expression 'psi[x](y)' in Sage
}}}
These conversions all go fine with the tree-walking translation of
maxima_lib (which gets used for some, but not all calculus operations):
{{{
sage: from sage.interfaces.maxima_lib import sr_to_max,max_to_sr
sage: T=maxima_calculus(sr_to_max(psi(psi(x,y),y))); T
psi[psi[x](y)](y)
sage: max_to_sr(T.ecl())
psi(psi(x, y), y)
}}}
Note that the regex-based "._sage_()" conversion will fundamentally have
trouble with nested square brackets:
{{{
sage: T._sage_()
TypeError: unable to make sense of Maxima expression 'psi[psi[x](y)](y)'
in Sage
}}}
As a first step we might want to change the regex to accept "non-]" inside
the square brackets to allow translation with non-numeric parameters. I
don't think anybody has seen an expression in the wild yet that has nested
square brackets (indeed, mostly the parameter is explicit numeric).
There are some other maxima functions that use square brackets too. These
might benefit from a similar treatment.
--
--
Ticket URL: <http://trac.sagemath.org/ticket/16732#comment:7>
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.
