#16732: Fix translation of psi(x,y) to/from maxima
------------------------------+------------------------
Reporter: nbruin | Owner:
Type: defect | Status: new
Priority: minor | Milestone: sage-6.3
Component: interfaces | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
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 completely recurse on the first argument,
> though:
> {{{
> sage: maxima_calculus(psi(psi(x,y),y))
> psi[psi(x,y)](y)
> }}}
> (note that the inner psi does not have the square brackets)
>
> 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/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.
--
--
Ticket URL: <http://trac.sagemath.org/ticket/16732#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.
