It's a fundamental point to know about Maple: just having some input lines in a worksheet or document doesn't really do anything. You have to execute them in order for them to have any effect. Moreover, what's important is the order in which commands are executed, not the order in which they appear in the worksheet. After messing about with the worksheet, making various changes and pasting things in various places, the worksheet won't reflect the current state of the Maple engine. That's why it's useful to have a restart at the beginning and hit the !!! button as Georgios suggested.

It's a fundamental point to know about Maple: just having some input lines in a worksheet or document doesn't really do anything. You have to execute them in order for them to have any effect. Moreover, what's important is the order in which commands are executed, not the order in which they appear in the worksheet. After messing about with the worksheet, making various changes and pasting things in various places, the worksheet won't reflect the current state of the Maple engine. That's why it's useful to have a restart at the beginning and hit the !!! button as Georgios suggested.

Taking a closer look, it seems MultiSeries[asympt] may be getting both the incomplete EllipticE and EllipticF wrong:

> with(MultiSeries):
  evalf(eval(EllipticE(t,sqrt(2))-convert(asympt(EllipticE
    (t,sqrt(2)),t),polynom),t=10^6));

0.+1.198140234*I

  evalf(eval(EllipticF(t,sqrt(2))-convert(asympt(EllipticF
     (t,sqrt(2)),t),polynom),t=10^6));

-2.622056139-.1e-8*I These might be branch cut problems.

Taking a closer look, it seems MultiSeries[asympt] may be getting both the incomplete EllipticE and EllipticF wrong:

> with(MultiSeries):
  evalf(eval(EllipticE(t,sqrt(2))-convert(asympt(EllipticE
    (t,sqrt(2)),t),polynom),t=10^6));

0.+1.198140234*I

  evalf(eval(EllipticF(t,sqrt(2))-convert(asympt(EllipticF
     (t,sqrt(2)),t),polynom),t=10^6));

-2.622056139-.1e-8*I These might be branch cut problems.

I think there's a more basic issue that ought to be addressed, besides the question of whether the expression we're taking a limit of simplifies under the assumption that k is an integer: should there be an option for taking limits as k -> infinity over the integers, rather than over the reals? Are there enough useful techniques that such a facility could use, besides the ones that work for limits over the reals?

I think there's a more basic issue that ought to be addressed, besides the question of whether the expression we're taking a limit of simplifies under the assumption that k is an integer: should there be an option for taking limits as k -> infinity over the integers, rather than over the reals? Are there enough useful techniques that such a facility could use, besides the ones that work for limits over the reals?

OK, you can enter them as binary operators in 2D Maple input using the Relational palette. In 1D Maple input, which is what your worksheet has, you would have to enter `⊢`(a, b) and `⊣`(a, b) instead of a ⊢ b and a ⊣ b. In any case, even if Maple can represent these as binary operators, they don't actually do anything, and certainly solve doesn't know anything about them. I'm not at all clear on what you expect solve to do with this mess.

OK, you can enter them as binary operators in 2D Maple input using the Relational palette. In 1D Maple input, which is what your worksheet has, you would have to enter `⊢`(a, b) and `⊣`(a, b) instead of a ⊢ b and a ⊣ b. In any case, even if Maple can represent these as binary operators, they don't actually do anything, and certainly solve doesn't know anything about them. I'm not at all clear on what you expect solve to do with this mess.

Right on all counts, I think. 1) limit does a real (or complex) limit, not a limit over integers, and is unaffected by assumptions on the limit variable. 2) sin(k*Pi) assuming k::integer; does return 0. 3) according to the help page ?operators,precedence, assuming has the second-lowest binding strength, above only :=. So sin(k*Pi) assuming k::integer, k=infinity; should be parsed as (sin(k*Pi)) assuming (k::integer, k=infinity); But there's still a bit of a mystery. > assume(n::integer): limit(sin(n*Pi),n=infinity); returns 0, because again sin(n*Pi) evaluates to 0. So why is this not the same as > limit(sin(k*Pi),k=infinity) assuming k::integer; ? Some more data points: > L(sin(k*Pi),k=infinity) assuming k::integer; returns L(0,k=infinity) (because sin(k*Pi) evaluates to 0 under the assumption k is an integer). L is not an actual procedure here. > Limit(sin(k*Pi),k=infinity) assuming k::integer; returns Limit(sin(k*Pi),k = infinity). Limit is also not an actual procedure. Clearly there's something special about limit and Limit as far as assuming is concerned: if its first argument contains a limit or Limit, it refrains from doing anything to the limit variable there. Indeed, confirmation of this comes from looking at the code for `assuming` (you need the back quotes because assuming is a reserved word): 113 dummies := map(proc (f, C) local t, eq, T; if op(0,f)::('identical(int,Int,sum,Sum,limit,Limit,product,Product)') and 1 < nops(f) and op(2,f)::('`=`') then t := op([2, 1],f); if member(t,C) then eq := t = `tools/gensym`(T); [f = subsop(1 = subs(eq,op(1,f)),2 = (rhs(eq) = op([2, 2],f)),f), eq] end if end if end proc,[op(indets(X,'function'))],map(lhs,cin)); Thus the same is true for int, Int, sum, Sum, product and Product.

Right on all counts, I think. 1) limit does a real (or complex) limit, not a limit over integers, and is unaffected by assumptions on the limit variable. 2) sin(k*Pi) assuming k::integer; does return 0. 3) according to the help page ?operators,precedence, assuming has the second-lowest binding strength, above only :=. So sin(k*Pi) assuming k::integer, k=infinity; should be parsed as (sin(k*Pi)) assuming (k::integer, k=infinity); But there's still a bit of a mystery. > assume(n::integer): limit(sin(n*Pi),n=infinity); returns 0, because again sin(n*Pi) evaluates to 0. So why is this not the same as > limit(sin(k*Pi),k=infinity) assuming k::integer; ? Some more data points: > L(sin(k*Pi),k=infinity) assuming k::integer; returns L(0,k=infinity) (because sin(k*Pi) evaluates to 0 under the assumption k is an integer). L is not an actual procedure here. > Limit(sin(k*Pi),k=infinity) assuming k::integer; returns Limit(sin(k*Pi),k = infinity). Limit is also not an actual procedure. Clearly there's something special about limit and Limit as far as assuming is concerned: if its first argument contains a limit or Limit, it refrains from doing anything to the limit variable there. Indeed, confirmation of this comes from looking at the code for `assuming` (you need the back quotes because assuming is a reserved word): 113 dummies := map(proc (f, C) local t, eq, T; if op(0,f)::('identical(int,Int,sum,Sum,limit,Limit,product,Product)') and 1 < nops(f) and op(2,f)::('`=`') then t := op([2, 1],f); if member(t,C) then eq := t = `tools/gensym`(T); [f = subsop(1 = subs(eq,op(1,f)),2 = (rhs(eq) = op([2, 2],f)),f), eq] end if end if end proc,[op(indets(X,'function'))],map(lhs,cin)); Thus the same is true for int, Int, sum, Sum, product and Product.

The "save" command used to have that functionality, more or less (saving all user-assigned variables) until Maple 7 or 8.

The "save" command used to have that functionality, more or less (saving all user-assigned variables) until Maple 7 or 8.

Maple's summation commands often work even when the series is divergent: the results obtained generally agree with what would be obtained by various summability methods (e.g. Cesaro, Abel, Borel). Consider e.g. > evalf(Sum((-1)^j,j=0..infinity)); 0.5000000000 To have Maple check for convergence of the series before computing the sum, set the environment variable _EnvFormal to false. On the other hand, that may err on the side of caution:

 
> _EnvFormal := false;
  evalf(Sum((-1)^(i+1)*(Psi(i+1)+gamma)*0.97^i,i=1..infinity));

Float(undefined)

Maple's summation commands often work even when the series is divergent: the results obtained generally agree with what would be obtained by various summability methods (e.g. Cesaro, Abel, Borel). Consider e.g. > evalf(Sum((-1)^j,j=0..infinity)); 0.5000000000 To have Maple check for convergence of the series before computing the sum, set the environment variable _EnvFormal to false. On the other hand, that may err on the side of caution:

 
> _EnvFormal := false;
  evalf(Sum((-1)^(i+1)*(Psi(i+1)+gamma)*0.97^i,i=1..infinity));

Float(undefined)

In general, consider an expression of the form A = sum (c[j](x[1],`...`,x[m])*D[j](f)(p[1](x[1],`...`,x[m]),`...`, p[n](x[1],`...`,x[m])),j=1..n) which you want to rewrite as sum(a[i](x[1],`...`,x[m])*diff(f(p[1](x[1],`...`,x[m]),`...`,p[n](x[1],`...`,x[m])),x[i]), i=1..m) Can it be done? Maybe. It requires solving the n linear equations c[j](x[1],`...`,x[m]) = sum(a[i](x[1],`...`,x[m])*diff(p[j](x[1],`...`,x[m]),x[i]),i=1..m) for the m unknowns a[i](x[1],`...`,x[m]) In a case such as this (n=2 < m=3) you would expect non-unique solutions. If n=m there may be a unique solution, while if n > m, there are usually no solutions. Anyway, "solve" should have no problem with this. In this example:

C:= [-1,-1]; P:= [x-y,z-y]; X:= [x,y,z];
eqs:= {seq(C[j] = add(a[i]*diff(P[j],X[i]),i=1..3), j=1..2)};
solve(eqs, {a[1],a[2],a[3]});

{a[1] = a[1], a[2] = 1+a[1], a[3] = a[1]}

eval(add(a[i]*Diff(f(op(P)),X[i]),i=1..3),%);

a[1]*Diff(f(x-y,z-y),x)+(1+a[1])*Diff(f(x-y,z-y),y)+a[1]*Diff(f(x-y,z-y),z)