You are getting bitten by the (1-x)^(m-r) term when x=1 and m=r.
The sum and the add commands handle that differently. Your m is a fixed integer, and for finite summation you should be using the add command and not the sum command. The sum command is for symbolic summation.
The sum command is seeing (1-x)^(m-r) become 0^(m-r) before r gets any numeric values. And so all it gets is just 0. At the top-level, outside of any call to sum or anything, you can see this with the following command, where r does not yet have any assigned value.
0^(m-r);
0
So the expression which you are summing evaluates prematurely to identically zero, even before sum begins its work. The is sometimes called "premature evaluation".
Now let's try you example with add instead of sum. Note that the add command has so-called special evaluation rules, which means that it delays evaluation of the first argument until after the summation index gets actual numeric values. So it delays evaluating (1-x)^(m-r) until r gets numeric values. So it will now get exact 0^0 when r=m which becomes 1.
g := x->x^2+3*x:
m := 20:
B := x->add(g(r/m)*binomial(m,r)*x^r*(1-x)^(m-r),r=0..m):
B(1);
4
Another way to proceed is to perform the finite summation (using either add or sum) for a general unassigned name (x or t or X or whatever) as the first step. In this case the subexpression (t-1)^(m-r) will become (t-1)^0 and produce just identically one (1) when r=m=20.
I'll use m:=3 below, to make it show less terms. That doesn't affect the discussion.
restart:
g := x->x^2+3*x:
m := 3:
B := x->add(g(r/m)*binomial(m,r)*x^r*(1-x)^(m-r),r=0..m):
p := B(t);
10 2 22 2 3
-- t (1 - t) + -- t (1 - t) + 4 t
3 3
eval(p,t=1);
4
Note that B(t) for unassigned t produces an expression. I could have used unassigned x here as well, instead of t. But your example already was a bit convoluted because you were using x in different nested procs as the formal parameter name.
But look, if you are only ever going to use the operator (procedure) B by calling it just once to get an expression... then it'd be easier to understand by just using an expression in the first place. I don't understand why so may people create operators just to ever use them once like this.
restart:
g := x->x^2+3*x:
m := 3:
B := add(g(r/m)*binomial(m,r)*x^r*(1-x)^(m-r),r=0..m);
10 2 22 2 3
-- x (1 - x) + -- x (1 - x) + 4 x
3 3
eval(B, x=1);
4
0
Bumbble Comm
On
Perhaps for Maple: $$0^0\neq 1\text{ ?}$$
I was able to replicate the problem
It is odd but $\mathrm{subs}(x=1,B(x))=4$ in Maple.
Also $ Z\mathrm{ := unapply (B(x),x)}$ gives $Z(1)=4$.
You are getting bitten by the
(1-x)^(m-r)term whenx=1andm=r.The
sumand theaddcommands handle that differently. Yourmis a fixed integer, and for finite summation you should be using theaddcommand and not thesumcommand. Thesumcommand is for symbolic summation.The
sumcommand is seeing(1-x)^(m-r)become0^(m-r)beforergets any numeric values. And so all it gets is just0. At the top-level, outside of any call tosumor anything, you can see this with the following command, whererdoes not yet have any assigned value.So the expression which you are summing evaluates prematurely to identically zero, even before
sumbegins its work. The is sometimes called "premature evaluation".Now let's try you example with
addinstead ofsum. Note that theaddcommand has so-called special evaluation rules, which means that it delays evaluation of the first argument until after the summation index gets actual numeric values. So it delays evaluating(1-x)^(m-r)untilrgets numeric values. So it will now get exact0^0whenr=mwhich becomes 1.Another way to proceed is to perform the finite summation (using either
addorsum) for a general unassigned name (xortorXor whatever) as the first step. In this case the subexpression(t-1)^(m-r)will become(t-1)^0and produce just identically one (1) whenr=m=20.I'll use
m:=3below, to make it show less terms. That doesn't affect the discussion.Note that
B(t)for unassignedtproduces an expression. I could have used unassignedxhere as well, instead oft. But your example already was a bit convoluted because you were usingxin different nested procs as the formal parameter name.But look, if you are only ever going to use the operator (procedure)
Bby calling it just once to get an expression... then it'd be easier to understand by just using an expression in the first place. I don't understand why so may people create operators just to ever use them once like this.