strange behaviour of maple when computing a sum with modulo
I have defined a simple function:
c(n) = 2 * floor((n mod 24) / 12)
I want to compute the sum c(0) + c(1) + ... + c(n) with Maple, but the s开发者_C百科ums Maple computes are wrong. Here is a screenshot of an example showing an obviously wrong sum: http://i.stack.imgur.com/BpmB2.png
I don't know what i am missing here ...
Thank you for your time
This sort of problem is known as premature evaluation. What happens is that sum
uses Maple's usual evaluation model, which includes evaluating arguments of procedure calls before actually doing the computation in the procedure body.
Look in particular at the result below of simply invoking creneau(i)
. That result is what sum
is seeing as its argument in your example. In other words, the mod
operation has occurred prematurely, because the call to creneau(i)
has evaluated prematurely.
creneau := n -> (2*floor((n mod 24)/12)):
creneau(38);
2
oops := creneau(i);
/1 \
2 floor|-- i|
\12 /
eval(oops, i=38);
6
add(oops, i=38..38);
6
sum(oops, i=38..38);
6
sum(creneau(i), i=38..38);
6
sum('creneau(i)', i=38..38);
2
add(creneau(i), i=38..38);
2
The usual way to fix this is to either use add
instead of sum
(since add
has so-called "special evaluation rules") or to wrap the first argument to sum
with so-called unevaluation- or delay-quotes.
What is unfortunate is that in 2D Math input mode the pretty-printed (Sigma) summation symbol looks the same for both sum
and add
. This makes this mistake all the harder to detect.
I would even guess that you had inserted the 2D Math summation from the Maple's Standard GUI's "Expression" palette, which unfortunately has sum
but not add
leading to more new user mistakes of this sort.
See also the help-page on special evaluation rules.
acer
精彩评论