Sage: Ticket #17502: fix interface to maxima.product
https://trac.sagemath.org/ticket/17502
<pre class="wiki">sage: maxima.product(k,k,1,n).sage()
k^n
</pre><p>
That's plain wrong of course and is not what Maxima says on the command line. The second argument (the running variable) apparently is completely ignored.
</p>
<pre class="wiki">%i4) product(k,k,1,n);
n
/===\
! !
(%o4) ! ! k
! !
k = 1
(%i5) product(k,k,1,n), simpproduct;
(%o5) n!
</pre><p>
The solution may depend on implementation of a symbolic product function.
</p>
<p>
See <a class="new ticket" href="https://trac.sagemath.org/ticket/22920" title="defect: Maxima library interface is broken for symbolic sums (new)">#22920</a> for the equivalent issue with sums.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/17502
Trac 1.1.6nbruinSun, 14 Dec 2014 22:17:53 GMT
https://trac.sagemath.org/ticket/17502#comment:1
https://trac.sagemath.org/ticket/17502#comment:1
<p>
Note that the same thing happens with
</p>
<pre class="wiki">sage: maxima.sum(k,k,1,n).sage()
k*n
</pre><p>
The problem is probably that these maxima routines aren't specially wrapped, so sage probably generates the following maxima session (roughly):
</p>
<pre class="wiki">(%i1) sage0: k;
(%o1) k
(%i2) sage1: k;
(%o2) k
(%i3) sage2: 1;
(%o3) 1
(%i4) sage3: n;
(%o4) n
(%i5) product(sage0,sage1,sage2,sage3);
n
(%o5) k
</pre><p>
Sage doesn't know that the parameter in the second slot is "special": it needs to be a name, and maxima treats it as just a name. If we wrap "product" as we do with "sum" the problem will go away. Plus, in the process you'll see sums don't get evaluated via the string interface at all.
</p>
TicketkcrismanMon, 15 Dec 2014 15:40:41 GMTcc set
https://trac.sagemath.org/ticket/17502#comment:2
https://trac.sagemath.org/ticket/17502#comment:2
<ul>
<li><strong>cc</strong>
<em>kcrisman</em> added
</li>
</ul>
TicketcharpentTue, 02 May 2017 06:08:36 GMT
https://trac.sagemath.org/ticket/17502#comment:3
https://trac.sagemath.org/ticket/17502#comment:3
<p>
Shouldn't that be considered a Maxima bug (and reported to Maxima as such) ?
</p>
TicketcharpentTue, 02 May 2017 06:09:26 GMTcc changed
https://trac.sagemath.org/ticket/17502#comment:4
https://trac.sagemath.org/ticket/17502#comment:4
<ul>
<li><strong>cc</strong>
<em>charpent</em> added
</li>
</ul>
TicketrwsFri, 05 May 2017 06:52:02 GMTdescription, milestone changed
https://trac.sagemath.org/ticket/17502#comment:5
https://trac.sagemath.org/ticket/17502#comment:5
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/17502?action=diff&version=5">diff</a>)
</li>
<li><strong>milestone</strong>
changed from <em>sage-6.5</em> to <em>sage-8.0</em>
</li>
</ul>
TicketcharpentTue, 09 May 2017 09:50:44 GMT
https://trac.sagemath.org/ticket/17502#comment:6
https://trac.sagemath.org/ticket/17502#comment:6
<p>
Extending <code>nbruin</code>'s remark as of two years (!!!) ago, a bit of tracing shows that the Maxima interface indeed binds the values of the arguments of the called function to temporary symbols, then <em>replaces</em> the original arguments with these symbols in the call to Maxima's function.
</p>
<p>
That is clever for several reasons, and not problematic <em>for "ordinary" functions</em>, i. e. Lisp function that <em>evaluate</em> their arguments. But Maxima's <code>product</code> is not an ordinary function, but a so-called special form. From <code>maxima.product</code> online help :
</p>
<pre class="wiki">'product' evaluates <expr> and lower and upper limits <i_0>
and <i_1>, 'sum' quotes (does not evaluate) the index
<i>.
</pre><p>
In other words, the second argument of Maxima's <code>product</code> is a <em>bound</em> variable, which (should) appear in the first argument. If we want to use the same renaming mechanism, we should substitute the new name of the second argument to this bound variable in the <em>first</em> argument, <strong>before</strong> renaming it. This is also the case for Maxima's <code>sum</code>.
</p>
<p>
The same is probably true for other Maxima's special forms (e. g. <code>define</code>, which could come handy for extending the Maxima library from Sage...).
</p>
<p>
I conclude that our current interface to Maxima is inadequate for special forms. I currently do not see how to determine at runtime if a given Maxima function is an ordinary function or a special form.
</p>
<p>
We could try to build a "blacklist" of known special forms, associating each of them to a custom handler (i. e. a dictionary). This is probably a bit of heavy lifting, and better Python programmers than I am may have a better idea...
</p>
<p>
If it turns out that there is a way to detect Maxima's special forms at runtime, another possible stopgap would be to raise an exception for any special form. Doesn't help much, but may at least avoid such nonsense as:
</p>
<pre class="wiki">sage: maxima.product(X(j),j,1,p).sage()
X(j)^p
sage: X(j).maxima_methods().product(j,1,p)
X(j)^p
</pre><p>
Should we ask <code>sage-devel</code> ?
</p>
Ticket