On Friday, December 30, 2016 at 3:54:08 PM UTC-8, Emmanuel Charpentier
wrote:
>
> This is what one expects from sage...
>
> sage: maxima("sum(j,j,1,p)").sage()
> sum(j, j, 1, p)
>
> This is what is expected from Maxima, as long as simpsum is not true
> (default)
>
> sage: maxima.sum(j,j,1,p).sage()
> j*p
>
> This is sheer, chemically pure (analytical quality) madness.
>
>
This is simply because the generic "expect interface" call amounts to
executing something along the lines
sage1 : j
sage2 : j
sage3 : 1
sage4 : p
sum(sage1,sage2,sage3,sage4)
which works fine for most function calls in maxima, but not for sum and
prod, where it is specified that the second parameter is *not* evaluated.
So you end up with evaluating sum(j,sage2,1,p) [where the binding of sage2
is ignored].
sage: maxima_calculus.sum(j,j,1,p).sage()
> j*p
>
> Madness again. This time, this is a method call...
>
Same code. It's a matter of legacy that maxima_lib evaluates its function
calls this way. It would be easy to make more efficient. In any case, it
means that maxima functions that have special evaluation rules for their
arguments will NOT be called correctly.
Indeed, it's not maxima's fault. However, maxima.sum and maxima.prod are
just there as generic things. We can't really expect the generic code to
divine the special evaluation rules. It would make sense to remove the
intermediate variables from the maxima_lib code. They are really quite
unnecessary there.
--
You received this message because you are subscribed to the Google Groups
"sage-support" 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 https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
