For efficiency, it'd be better to use a custom procedure for this purpose rather than constructing a lengthy expression of ands and ors using seq. This is because in the vast majority of cases the evaluation can be terminated early without examining every (or even most) of the elements. Here's the procedure:

LexicographicOrder:= proc(a, b)
local k, na, nb;
   (na,nb):= (numelems(a), numelems(b));
   for k to min(na,nb) do
      if a[k] < b[k] then return true 
      elif a[k] > b[k] then return false
      end if
   end do;
   evalb(na < nb)
end proc:

If you're comparing lists of length 100, the procedure should be thousands of times faster for the average case than the construction with seqs. Constructing sequences of numerous subsequences is a relatively expensive operation in Maple.

Your second form and displayed form, both of which show the series as externally multiplied, are mathematical nonsense. But your first form, which has the series nested, makes sense. You said that it gives wrong answers. Note that the results below differ from your desired results by a factor of exactly 3. You must be missing a 3 somewhere.

Download Solve_series.mw

Note that the -1/(k+1) coefficient in front of eq is superfluous. It couldn't possibly change the results because eq is equated to 0.

The polynomial equation is sixth degree in v. It's mathematically impossible to solve it. This is not a limitation of Maple.

The package linalg, and the commands evalm and crossprod had been superceded long before Maple 13. Also, you can reduce the repetition in your code by using elementwise operators:

restart:
ly:= 9.4607e15:
M0:= 1.99e30:

M:= M0*[2.20, 2.00, 1.50, 3.00]:

r:= [<-3, 3, 0>, <0, -2, 0>, <1, 2, 0>, <6, 4, 0>]*ly:
v:= [<25, 15, 0>, <20, -20, 0>, <-5, -25, 0>, <15, 0, 0>]*1e3:

Mtot:= `+`(M[]):

rcm:= `+`((M*~r)[])/Mtot:
vcm:= `+`((M*~v)[])/Mtot:

with(LinearAlgebra): 
add(r[i] &x (M[i]*v[i]), i= 1..nops(v)) - rcm &x (Mtot*vcm);

Other than the names, there is no similarity between eval and evalf. The command for evaluating an expression with free variables at values for those variables (a "point") is eval. The command for converting expressions with no free variables into complex decimal approximations is evalf. If you use evalf on an expression with free variables, then it is simply applied to the subparts that don't. It's not possible to use one command in place of the other.

You'll need to post the series problem that you're talking about to get further advice.

Induction is a proof technique. The corresponding programming technique is called recursion. This means that the procedure calls itself.

(A half a line of code omitted.)

That's all there is to it.

The error message says that it wants an indication of the dependent variables. So, change the pdsolve command to

pdsolve([pde, bc], u(x,t))

Diff(int(value(z), t), t);

The integrand has singularities at -I, 2*I, and 5. All of these are at distance greater than 1 from sqrt(11/2). So no singularities are enclosed by the path of integration. So the answer is 0.

If Maple ever gives you 2D output that you don't understand, just use lprint(%) to see the 1D equivalent. In this case, it will reveal the LerchPhi.

I don't think that dsolve's BVP solvers can handle complex numbers. But your BVP contains a parameter, A3. We can solve for this parameter and then use one of dsolve's IVP solvers, which do handle complex numbers. To solve for A3, note that the right side of your ODE doesn't contain the dependent variable, u. Thus we can use a combination of numeric integration and fsolve.
 

Download Complex_BVP.mw

The cause of the anomaly that you described is that print doesn't return values; it merely displays them in your worksheet. The purpose of print is to display supplementary information from the middle of a procedure. It is not appropriate to use it at the end of a procedure to return the procedure's main return value. If you do use it like this, the actual returned value (not the displayed value) is NULL, which is of type exprseq, which is what you're experiencing. So, all you need to do is change print(Hm) to simply Hm.

I think that you may have the mistaken idea that a "statement" needs to be on a single line. Actually, there's no practical limit to the number of lines that it can take, the number of substatements internal to it, or the depth of their nesting.

Change

if m1 <= 2^(2*k-1) then t1 := (C+(-A1*(m1^2)))/A2 end if;
Do (t1);

to

if m1 <= 2^(2*k-1) then
   t1 := (C+(-A1*(m1^2)))/A2;
   Do (t1)
end if;

And do likewise for the other if-then blocks.

The line

E2:= V(x2);

should be

E2:= V(x2(i));

It's not a source of the error, but I'm concerned about your use of Seed. What is its significance? Why not use rand()?

You should not use randomize() until you have your code running correctly without it because its use will make some bugs harder to find.

Please post code in plaintext form, or post a worksheet. I was unable to test my answer above because I couldn't run your code because it's in a form that can't be copied-and-pasted.

If the function has a Taylor series at x=a, then that's what's returned. For complex-valued functions (which most functions are), having a Taylor series at x=a is equivalent to the function being differentiable throughout an open set containing x=a. Next, if it has a Laurent series at x=a, then that's what's returned. Having a Laurent series at x=a is equivalent to there being a positive integer n such that (x-a)^n*f(x) has a Taylor series at x=a. Finally, if a more-generalized type of series can be found, then that's what's returned. I don't know the details of these more-generalized series, but my first guess is that they're always of the form M((x-a)*g(x-a)), where M(z) is a Maclaurin series and g(x) is a relatively simple function (such as ln(x) or x^r for some r, 0 < |r| < 1) that is not differentiable at x=a.