[MUG] a bug or a feature?

[MUG] Re: a bug or a feature?
Author: Maple User Group    Posted: Mon, 6 May 2002 13:38:22 -0400 (
>> From: Maple User Group "maple_gr" | >> From: "Rouben Rostamian" "rostamian" | | The sum() and add() functions contradict each other in Maple 7: | | > restart: | > f := x -> sum(a[k]*x^k, k=0..5): | > g := x -> add(a[k]*x^k, k=0..5): | | Now test: | | > f(x) - g(x); | 0 | So far, so good. But... | | > f(0); | 0 | | > g(0); | a[0] | | Therefore f(0) != g(0). Is this discrepancy inevitable by design | or can it be smoothed out in future releases? | In other words, is this a bug or is it a feature? -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Date: Wed, 1 May 2002 15:05:56 -0700 (PDT) From: Robert Israel "israel" To: "maple-list" Subject: a bug or a feature? Really the problem is this: > 0^k; 0 which is of course wrong if k<=0. This might be considered a bug, but it is long-established behaviour. As in most procedures, the arguments to "sum" are evaluated before "sum" actually starts, so f(0) evaluates sum(0, k=0..5) which of course produces 0. On the other hand, "add" has special evaluation rules and substitutes the k values before evaluation. Note also that 0^k = 0 seems to occur at the "automatic simplification" stage, so if entered directly from the command line rather than in a procedure it can defeat "add" as well: > add(0^k, k=0..5); 0 Robert Israel "israel" Department of Mathematics http://www.math.ubc.ca/~israel University of British Columbia Vancouver, BC, Canada V6T 1Z2 -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Date: Wed, 1 May 2002 19:30:17 -0400 (EDT) From: Carl Devore "devore" To: "maple-list" Subject: a bug or a feature? I consider it a feature, not a bug. add and sum are not the same thing. If they were the same, why have different commands? There will probably be much debate abut that. The discrepancy comes from the different order of evaluation of x^k. If x is a name then x^0 is 1. If k is a name, then 0^k is 0. add "plugs in" the values of k first and sum plugs in the value of x first. I do not recommend that you try to "smooth out" this discrepancy -- you will find ultimately that it is impossible -- but you can do this: f:= unapply(sum(a[k]*x^k, k= 0..5), x); or f:= x-> sum(a[k]*''x''^k, k= 0..5); (those are doubled single quotes) and in either case f(0) will return a[0]. In the other direction, g:= x-> eval('add'(a[k]*x^k, k= 0..5)); and now g(0) will return 0. -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Date: Thu, 02 May 2002 08:51:27 +0200 From: Helmut Kahovec "helmut.kahovec" To: "maple-list" Subject: a bug or a feature? It is a feature: The library function sum() evaluates its arguments whereas the kernel function add() does not. 0^n evaluates to 0 but 0^0 evaluates to 1. Thus we have in turn: > restart; > 0^n,0^0; 0, 1 > z,n:=0,0: z^'n',z^n; 0, 1 > f:=x->sum(a[k]*'`^`'(x,k),k=0..5); > f(0),g(0),f(x)-g(x); a[0], a[0], 0 > f:=x->sum(a[k]*''x''^k,k=0..5); > f(0),g(0),f(x)-g(x); a[0], a[0], 0 Kind regards Helmut -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- From: "Dr Francis J. Wright" "F.J.Wright" To: "maple-list" Subject: a bug or a feature? Date: Thu, 2 May 2002 14:53:02 +0100 I think the difference arises because add and sum have different argument evaluation semantics: sum evaluates its arguments before summing whereas add does so after summing, which has the effect of changing the order of taking limits when evaluating 0^0. So > g := x -> add(a[k]*x^k, k=0..5): g(0); is the same as > add(a[k]*x^k, k=0..5); 2 3 4 5 a[0] + a[1] x + a[2] x + a[3] x + a[4] x + a[5] x > subs(x=0, %); a[0] whereas > f:= x -> sum(a[k]*x^k, k=0..5): f(0); is the same as > sum(a[k]*0^k, k=0..5); 0 Hence, one way to rewrite g so that it behaves the same as f is like this: > g := proc(x) > local k; > a[k]*x^k; add(%, k=0..5) > end proc: > g(0); 0 Similar, one way to rewrite f so that it behaves the same as g is like this: > f := proc(x) > local X; > subs(X=x, sum(a[k]*X^k, k=0..5)) > end proc: > f(0); a[0] So, regardless of whether the underlying behaviour is a bug or a feature, it is possible to get whatever result you want! Francis

Previous by date: [MUG] Maximize/minimize,  Jim Gunson
Next by date: [MUG] Re: Maximize/minimize, Carl Devore
Previous thread: [MUG] FW: Position at WMI, L Bernardin
Next thread: [MUG] Maximize/minimize,  Jim Gunson