fix interface to maxima.product

[rwst]

sage: maxima.product(k,k,1,n).sage()
k^n

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.

%i4) product(k,k,1,n);
                                      n
                                    /===\
                                     ! !
(%o4)                                ! !  k
                                     ! !
                                    k = 1
(%i5) product(k,k,1,n), simpproduct;
(%o5)                                 n!

The solution may depend on implementation of a symbolic product function.

See #22920 for the equivalent issue with sums.

CC: @kcrisman @EmmanuelCharpentier

Component: interfaces

Issue created by migration from https://trac.sagemath.org/ticket/17502

[nbruin]

comment:1

Note that the same thing happens with

sage: maxima.sum(k,k,1,n).sage()
k*n

The problem is probably that these maxima routines aren't specially wrapped, so sage probably generates the following maxima session (roughly):

(%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

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.

[EmmanuelCharpentier]

comment:3

Shouldn't that be considered a Maxima bug (and reported to Maxima as such) ?

[EmmanuelCharpentier]

comment:6

Extending nbruin'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 replaces the original arguments with these symbols in the call to Maxima's function.

That is clever for several reasons, and not problematic for "ordinary" functions, i. e. Lisp function that evaluate their arguments. But Maxima's product is not an ordinary function, but a so-called special form. From maxima.product online help :

'product' evaluates <expr> and lower and upper limits <i_0>
and <i_1>, 'sum' quotes (does not evaluate) the index
<i>.

In other words, the second argument of Maxima's product is a bound 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 first argument, before renaming it. This is also the case for Maxima's sum.

The same is probably true for other Maxima's special forms (e. g. define, which could come handy for extending the Maxima library from Sage...).

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.

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...

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:

sage: maxima.product(X(j),j,1,p).sage()
X(j)^p
sage: X(j).maxima_methods().product(j,1,p)
X(j)^p

Should we ask sage-devel ?