Each seq command can only have one index variable. So, for example, if you wanted to generate all pairs of positive integers less than 4, you could use a double seq, like this:

seq(seq([i,j], i= 1..3), j= 1..3)

You could just as well iterate the j in the inside seq and i in the outside, which would generate the same pairs in a different order.

But you CAN'T do this:

seq([i,j], i= 1..3, j= 1..3)

simply because the syntax won't allow it, even though the concept is sensible. You attempted to do something like this, which was the reason for your error.

This is what I would do:

U:= eval(Array(1..2, 1..2, 1..2, 1..4, ()-> u[args]), Sol);

Now, U[2, 1, 1, 3], for example, would be the Array entry whose value corresponds to u[2, 1, 1, 3] in Sol. Unlike the other solutions based on either the assignment operator or assign command, this method does not cause any change to Sol or to the u's. Thus the u's can be used again as variables, perhaps to obtain another solution. This re-use of the u's would not affect the values now stored in the Array.

My method will work even if there are some index combinations for which there is no corresponding u in Sol.

My general policy is to avoid making any direct assignments to the fundamental variables of a problem (such as the independent and dependent variables); rather, I store solution values somewhere else, such as the Array, or just keep them in Sol for use on an as-needed basis. The command eval(expr, Sol) can be used to apply the values to any expression expr containing any of the u's.

In my code that you refer to, there is a line

Jxy:= ....

The purpose of that line is to list (in jet notation) the derivatives that you want to consider. In that case, I wrote some fancy code to extract all second derivatives of u and v with respect to x and/or y, but I could've just as well have written simply

Jxy:= {u[x,x], u[x,y], u[y,y], v[x,x], v[x,y], v[y,y]}.

Likewise, you can put whatever you want in the set. This is the only change that's needed.

Note that if the equation is nonlinear with respect to the desired derivatives, then a concept such as "the coefficient of u[x,x]" is not very meaningful. Nonlinearity of the overall equation is irrelevant; it's the linearity with respect to the desired derivatives that matters.

The problem is not recursive functions but a recursive assignment statement. Your first assignment statement inside the loop has x[n+1] on both sides of the assignment operator.

Assuming that I'm correct about the corrections that need to be made to the algorithm, as noted in my Reply above, then a translation of the algorithm into Maple is

Paar:= proc(M::Matrix)
local H, R:= copy(M), maxij, newcol;
     do
          maxij:= [max[index]((H:= rtable(antisymmetric, R^+.R)))];
          if H[maxij[]] <= 1 then return R fi;
          R:= <R|(newcol:= R[..,maxij[1]] *~ R[..,maxij[2]])>;
          R[..,maxij]:= R[..,maxij] *~  (1 -~ <newcol|newcol>)
     od
end proc:

 Note that I chose to return a new matrix rather than modify the input matrix M.

The above uses Maple 2018 syntax for embedded assignments. If you need to use it in an older Maple, let me know. It'll be easy to retrofit.

Use

op~([[1,2],[-2,1]], simplify(piecewise(op(f(t)), undefined)));
                                           [-1, 1]

We essentially have a pair of recurrences, one for a(n) and one for S(n). If we can eliminate one of two variables, then we can use the makeproc option of rsolve to get a numerical solver for the other. This is easy because a(n) = S(n) - S(n-1). Thus

SP:= rsolve({S(n)-S(n-1) = 2*S(n)^2/(2*S(n)-1), S(1)=1}, {S(n)}, makeproc):
SP(100)-SP(99);
                                          -2/39203

Note that no summation command is needed; there's not even one hidden in the procedure SP. I hope that Acer considers this to be the clever solution that he was expecting. 

The recurrence is nonlinear, so I don't have much hope for a closed-form solution.

You can extract the coefficients like this:

Jets:= {u,v}(x,y);
wave:= #You need to apply ToJet to the whole equation.
   ToJet(
      x*y*(diff(u(x,y),y,y) - diff(c(x,y)^2*diff(u(x,y),x),x)) - 
         TotalDiff(F(x, y, u[], u[1], u[2], v[], v[1], v[2]), y) + 
         TotalDiff(P(x, y, u[], u[1], u[2], v[], v[1], v[2]), x) = 
         0, 
      Jets
   );
#These are the 2nd derivatives that you want:
Jxy:= indets(wave, index~(op~(0,Jets), identical(op~(Jets)[])$2));
#The main coefficient-extraction command:
Cfs:= coeffs(collect((lhs-rhs)(wave), Jxy, distributed), Jxy, 'terms'):
#It needs to have its output put into a user-friendly form:
Cfs:= table([terms]=~[Cfs]):
#Now all coefficients are available by indexing Cfs:
Cfs[1]; #"constants" term
Cfs[u[x,x]]; #coeff of u[x,x] term

Where to start: Look up command ?addcoords

You are unknowingly mixing up types and properties in that you're expecting a type to act like a property. Here's a discussion of both. Although it may seem like properties are much more powerful, you'll definitely want to stick with types in this case for their robustness, definitiveness, and simplicity of programming.

Given any Maple data structure x and any type t, either x definitely has or definitely doesn't have type t---there are never nebulous cases where possesion of the type can't be determined (due to x being symbolic or any other reason)^[*1]. So, if x is not numeric, then it's definitely not of type integer nor type even. Examples of types include numeric, integer, even, odd, algebraic, and complexcons.

Types can be contrasted with properties, which can be nebulous (i.e., subject to 3-valued logic). The commands to check whether x has property p are is(x::p) and coulditbe(x::p), and one of these four cases applies:

1. x definitely has the property;
2. x definitely doesn't have the property;
3. mathematically, there's not enough given information (in the current assumptions) to determine whether x has the property;
4. Maple cannot determine whether x has the property although there's theoretically enough information to make that determination.

The corresponding returns from is or coulditbe are true, false, FAIL, FAIL, respectively, for the four cases. These are the values of Maple's 3-valued logic. (No attempt is made to distinguish cases 3 and 4.) The difference between is and coulditbe is significant when x is symbolic and it corresponds to universal or existential quantification:

• Universal (is): Do all possible values of x under the current assumptions have the property?
• Existential (coulditbe): Does there exist some value of x under the current assumptions that has the property?

An example of a property that isn't also a type is real. Unfortunately, there are several names which can be used as both types and properties, easily leading to the confusion that caused you to ask this Question.

Obviously from the above discussion, working with properties is quite subtle, and I haven't even discussed what precisely is meant by the current assumptions. However, it's far more important that you learn to work with types than with properties, so I won't discuss properties any further in this article.

It happens very often that you want a procedure to do nothing when it's given non-numeric input or other input that it can't or shouldn't handle. Formally speaking, you want the procedure to return unevaluated. In these cases, the procedure's return value can be coded as 'procname'(args). Thus, your even/odd procedure could be

M:= (n::And(algebraic, Or(integer, Not(complexcons))))-> 
   `if`(n::integer, n mod 2, 'procname'(args))
:

Notes:

• In those cases where it'll do the job, `if` is far more efficient and far more robust than piecewise.
• When a::b appears in a context requiring a true/false value, it's essentially equivalent to type(a, b), but more robust because it works even if a = NULL.
• My type declaration for n---And(algebraic, Or(integer, Not(complexcons)))---is intended to exclude (with an error condition) manifestly garbage input such as 6.3 or [x, y, z]; i.e., things that could never be integers even if their symbols, if any, were given numeric values.

[*1] It's possible to define types (and this can very easily happen through sloppy programming) that do not return true, false, or error for some inputs. There is never any good reason to do this, and it can lead to very serious problems, including kernel crashes. (Note that error is not the same as FAIL.)

Please respond to my Answers!

Use plots:-display(a, b, c) because display is in the plots package and always has been.

Your older worksheets probably included the command with(plots), which would've allowed future references in the same session to be display(...) rather than plots:-display(...); however, I prefer to explicitly use package-name prefixes such as plots:- whenever possible.

If you have a solution set or list named, for example, Sol, and it contains equations such as {A = 3.54, B = 4.67}, then you can do assign(Sol).

To go downhill at locally maximal descent (like water would), follow the negative gradient. Here, I've done it with dsolve, but there may be another way. The path will stop at any local minimum or saddle point, of course, which is what happens in this plot.

restart:
f:= (x,y)-> 3*(1-x)^2*exp(-x^2-(y+1)^2) - (2*x-10*x^3-10*y^5)*exp(-x^2-y^2) - 1/3*exp(-(x+1)^2-y^2):
bp:= <0.2, 1.4>: #initial point.
Sol:= dsolve(
   {diff(X(t),t) = -D[1](f)(X(t),Y(t)), diff(Y(t),t) = -D[2](f)(X(t),Y(t)), X(0)=bp[1], Y(0)=bp[2]},
   numeric
):
plots:-display(
   plot3d(f, -3..3, -3..3),
   plots:-odeplot(Sol, [X(t), Y(t), f(X(t),Y(t))], t= 0..1, color= red, thickness= 3),
   orientation= [-40,60,0]
); 

My choice of t=1 as an endpoint for the integration was just a guess, but it's at or near a local minimum, as can be seen by rotating the plot.

The procedure Diffs that you want can be written like this:

Diffs:= proc(e::algebraic)
local t;
     subsindets(
          subsindets(
               diff(subsindets(e, And(name, Not(constant)), n-> n(t)), t),
               'diff'(anyfunc(identical(t)), identical(t)),
               d-> PutDelta(op([1,0], d))
          ),
          anyfunc(identical(t)),
          f-> op(0,f)
     )
end proc:

where PutDelta is as specified by Acer.

As far as your computer cares, there's no meaningful difference between a .txt and a .mpl file. The only purpose of ".mpl" is long-standing tradition (at least 42 years) that plaintext files of computer code have a file "extension" (the part after the dot) that indicates the language that the file is written in. So, there's no conversion; you simply rename the file. Alternatively, Maple would be just as happy to read the .txt file.