Opened 6 years ago
Last modified 4 years ago
#17502 new defect
fix interface to maxima.product
Reported by: | rws | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-8.0 |
Component: | interfaces | Keywords: | |
Cc: | kcrisman, charpent | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
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.
Change History (6)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
- Cc kcrisman added
comment:3 Changed 4 years ago by
Shouldn't that be considered a Maxima bug (and reported to Maxima as such) ?
comment:4 Changed 4 years ago by
- Cc charpent added
comment:5 Changed 4 years ago by
- Description modified (diff)
- Milestone changed from sage-6.5 to sage-8.0
comment:6 Changed 4 years ago by
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 its summand <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
?
Note that the same thing happens with
The problem is probably that these maxima routines aren't specially wrapped, so sage probably generates the following maxima session (roughly):
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.