@mweisbr It might be worth noting that that LinearAlgebra's DeleteRow and DeleteColumn procedures do not operate in-place; instead they return a submatrix of the original. That is why your original did not do what you expected, and why Kitonum's modification works.

@acer Thanks for the clarification---the statement seemed a bit odd, I hadn't considered an alternative interpretation. Yes, implementing a max operation with a custom comparator "manually" is a bit of a pain, though any approach is going to be O(n)... Hmm, I wonder if min/max switches to a parallel routine with a large enough container; sort does.  A clever method is to use an object to redefine <, then let min/max do the work:

Pair := module()
option object;
local x,y;
local
    ModuleApply :: static := proc()
        Object(Pair,_rest);
    end proc;

local
    ModuleCopy :: static := proc(self :: Pair
                                 , proto :: Pair
                                 , x := proto:-x
                                 , y := proto:-y
                                )
        self:-x := x;
        self:-y := y;
    end proc;

local
    ModulePrint :: static := proc(self :: Pair)
        ':-Pair'(self:-x, self:-y);
    end proc;

export
    `<` :: static := proc(a :: Pair, b:: Pair)
        a:-x < b:-x or a:-x = b:-x and a:-y < b:-y;
    end proc;
end module:

P1 := Pair(1,2):
P2 := Pair(2,3):
P3 := Pair(1,1):

min([P1,P2,P3]);
                    Pair(1,1)

Of course, no one is going to create an object just to compute a minimum, that approach is useful only if you already have an object and need to do so. It would be easier to write a simple min/max routine that took a custom comparator.

@acer Computing max with a user-supplied comparator shouldn't be less efficient than sorting with one.  Regardless, it would be nice if, similar to sort, a 'key' option were added to max.  That would be efficient. Of course, one can do the equivalent in a few commands: map the key funtion over the list, then call max with the index index (8-) and apply that to the original list.  But a key option would be cleaner. 

@tomleslie As the help page for evalb describes, its purpose is to convert a relation to a true/false/FAIL value, not to determine whether it is a tautology. Using simplify here is generally too expensive and unwarranted. I use it in programs for its intended purpose, say, to convert x < y, with x and y numeric values, to true/false.

@acer An interesting extension would be to have Maple-side access to the GUI's printing engine, so that one could, say, send a table in xml format and have it printed.

I don't have an answer, but a question. What is the key that would be used to sort the tables (alphabetically)? The only label I'm aware is the table ID, which for these tables is Table0, Table1, etc, and they already appear alphabetically. Do you mean based on the initial content (header) in each table?

@shimaa sadk In the call to solve, use a list for the solving variables, the result is then a list of lists of equations in the order you supplied.  For example

sols := solve({x+y=1, x-y=0}, [x,y]);
                    sols := [[x = 1/2, y = 1/2]]

To assign these to, say, xsol and ysol, you can do

(xsol,ysol) := op(rhs~(sols[1]));
              xsol, ysol := 1/2, 1/2

@Carl Love Note that in the Standard worksheet, currentdir is displayed at the bottom of the screen in the status bar (if it is enabled). Clicking on it opens a dialog that allows changing the directory (which can also be done via the currentdir command, as noted).

X and Y are lists. The index 0 cannot be used with a list (negative indices can be used, with -1 corresponding to the last element in the list).

Your hunch about seq(i, i=0..infinity) raising an error is correct; for that to yield a result Maple would have to return an expression with an infinite number of terms.  On the other hand, seq(i, i=0..-infinity) is allowed because that evaluates to an empty sequence. If the optional third argument is passed to seq specifying a negative step, say, seq(i, i=0..infinity, -1) then the same error would be raised.

@Earl The map command, with no index, maps the first argument over the second, passing additional arguments, as is, to the first (the operator). To see this, do

map(f, [1,2,3], [a,b], c);
           [f(1, [a, b], c), f(2, [a, b], c), f(3, [a, b], c)]

While I don't really see the point, you could do

f := simplify@expand@rcurry(eval,x=y+1):
f(expr);

The following is clearer and more efficient

f := expr -> simplify(expand(eval(expr,x=y+1))):
f(expr);

While it doesn't effect the result, the expression in the plot statements should be u, not u(x).

@Nemo_ The reason kitonum suggested that a restart would be necessary is that, for the assign procedure to work, the left side of each equation must be a name. If you have already assigned an expression to A or B, it will fail as Maple cannot assign to an expression (both sides of the equations in a call to assign are evaluated). That is not an issue with the assignment operator (:=) because the left side is not evaluated.

Presumably one of the arguments evaluated to NULL. Or you did something wrong. Hard to say without seeing what you are doing.

@mmcdara I don't know of one.  On my linux box the character displays as an unfilled rectangle, so was easy to spot.