After all that, this is pretty much saying that Re(z) = abs(z)*cos(arg(z)) where z = GAMMA(a+b*i). Well, it changed b to |b|...

After all that, this is pretty much saying that Re(z) = abs(z)*cos(arg(z)) where z = GAMMA(a+b*i). Well, it changed b to |b|...

LinearAlgebra has been around since Maple 6, which is about 7 years old, and VectorCalculus since Maple 8, about 5 years old. Together these duplicate substantially all of linalg's functionality. Already in Maple 8 the help page for linalg said it was superseded. I really doubt that Maplesoft will ditch linalg any time soon, though, mainly because of all that legacy code.

It also works if you specify method=dverk78 or classical or probably anything other than rkf45.

Even better: use * and there's never any problem. Implicit multiplication is a good example of how trying to make something easier can end up making it more complicated.

Once you know the null space is one-dimensional, you might try to use LinearSolve on the matrix with one row removed. Generically that will have a one-parameter solution; the product of the missing row and this vector should be 0 (but may not be obviously 0, depending on what kind of coefficients you have). For example, consider the matrix

 > A := Matrix([[a+b+c, a+b+c, a+c,   c], 
                  [c,     c,     b+c, a+c], 
                  [a+b,   a+b+c, c,   a+c], 
                  [0,     a+c,   0,     a]]);

where a, b, c are expressions such that Determinant(A) happens to be 0 (but perhaps Maple doesn't know that). You can try

 > LinearSolve(A[1..3,1..4],<0,0,0>);

RTABLE(160778436,MATRIX([[_t[4]*a*(a^2+2*c*a+2*b*a+b^2+3*c*b)/c/b/(a+b+2*c)], [-(a^3+2*b*a^2+c*a^2-2*c^2*a+a*b^2+3*a*c*b+c^2*b)*_t[4]/c/b/(a+b+2*c)], [-(a^2+b*a+2*c*a+c*b)*_t[4]/b/(a+b+2*c)], [_t[4]]]),Vector[column]) which, assuming the denominators are not 0, should actually be the null space of A. Note that this might not work if the rows you use are linearly dependent.

Once you know the null space is one-dimensional, you might try to use LinearSolve on the matrix with one row removed. Generically that will have a one-parameter solution; the product of the missing row and this vector should be 0 (but may not be obviously 0, depending on what kind of coefficients you have). For example, consider the matrix

 > A := Matrix([[a+b+c, a+b+c, a+c,   c], 
                  [c,     c,     b+c, a+c], 
                  [a+b,   a+b+c, c,   a+c], 
                  [0,     a+c,   0,     a]]);

where a, b, c are expressions such that Determinant(A) happens to be 0 (but perhaps Maple doesn't know that). You can try

 > LinearSolve(A[1..3,1..4],<0,0,0>);

RTABLE(160778436,MATRIX([[_t[4]*a*(a^2+2*c*a+2*b*a+b^2+3*c*b)/c/b/(a+b+2*c)], [-(a^3+2*b*a^2+c*a^2-2*c^2*a+a*b^2+3*a*c*b+c^2*b)*_t[4]/c/b/(a+b+2*c)], [-(a^2+b*a+2*c*a+c*b)*_t[4]/b/(a+b+2*c)], [_t[4]]]),Vector[column]) which, assuming the denominators are not 0, should actually be the null space of A. Note that this might not work if the rows you use are linearly dependent.

The quotes are not the problem. The problem is that

> sum(min(2,j)/factorial(j),j=1..infinity);

returns 2*exp(1)-2 when it should return 2*exp(1)-3. Note that

> sum(piecewise(j<=2,j,2)/factorial(j),j=1..infinity);

gives the correct answer.

Your title is a bit misleading, since in both versions you're calling foo recursively. The question is whether to use map or a for loop. By the way, you don't need the "op", you can say

 for x in s do ... 

. And there's a third way:

> add(foo(x), x = s);

I tried all three ways on a simple example, a polynomial with 100000 terms and a function that returned 1. I found that "map" was the fastest, with "add" just slightly slower, and the for loop was over 30% slower. I think the general principle here is that for efficiency it's best to use built-in functions such as map and add as much as possible.

Of course Maple can't issue an error when the procedure is defined. What I meant was, there's no check for recursive assignment when the procedure is called. For example:

> p := proc() global q; q:= [q,1]; foo end;
  p();

produces no error. You only get an error if you try to evaluate q (as would happen, e.g., if you tried p() a second time).

... "the appropriate symbol" is & lt; (without the space after &). inequal is for regions defined by linear inequalities. For a region defined by one nonlinear inequality, you might try implicitplot with the option filled=true. I would have recommended "inequalities" in my Maple Advisor Database, but I see that this doesn't work in Maple 11.

... "the appropriate symbol" is & lt; (without the space after &). inequal is for regions defined by linear inequalities. For a region defined by one nonlinear inequality, you might try implicitplot with the option filled=true. I would have recommended "inequalities" in my Maple Advisor Database, but I see that this doesn't work in Maple 11.

I don't know if I'd call this error message misleading: it does describe what has happened, but not why it has happened (is it really fair to ask Maple to figure that out?). You can use tracelast to pin down the error a bit more. In this case you see that it occurred in statement number 3:

 EE called with arguments: a, b
 #(EE,3): if not has(N,n2) then ... end if
Error, (in EE) too many levels of recursion

Indeed, simply evaluating N now creates an error.

> N;
Error, too many levels of recursion

What happened here? Since N was initially unassigned, has(N,n1) returned false, so Maple executed the assignment

  N:=[op(N),n1];

Now op(N) is just N, so this is a recursive assignment: you're assigning N a value that contains N itself. Rather surprisingly, Maple doesn't produce an error here, although the same assignment at top level would produce "Error, recursive assignment". The error occurs when Maple tries to evaluate N in the "has(N,n2)". It is an infinite recursion: in order to evaluate N, Maple must evaluate N, and then ... One way you might prevent this sort of error is with type-checking. You might try

> kernelopts(assertlevel=1):
> EE := proc(n1,n2)
  global N;
  ASSERT(N::list,"N must be a list");
  ...

Of course, if you thought of inserting this ASSERT statement you might just as well have included

> if not N::list then N := [] end if;

Good point: it must be a bug somewhere in solve. In fact Maple's solution satisfies that equation for _NN1 = -1 and _NN1 = 0 (and only those). Similarly, consider the equation x*exp(x)=1: Maple gives the solutions as LambertW(_NN1, 1), and in fact this is a solution for all integers _NN1.

When 0 > x > -exp(-1) there are two real branches of LambertW(x), the 0 branch and the -1 branch. So:

> _EnvAllSolutions:=true:
  a:=.5: s:=.2:
 k:= 0.98: v:= 0.4: 
 sol:=solve(1+(5*x)*(log(5*x)-1)=.5*v-sqrt(k)*x, x);
 eval(sol,_NN1=-1);
 eval(sol,_NN1=0);

sol:=0.2000000000*exp(LambertW(_NN1, -0.3587413396) + 0.8020101013) 0.1288902501 0.2019811136 However, it doesn't always work out so nicely: even with _EnvAllSolutions = true, solve doesn't usually find all solutions to a complicated transcendental equation.