The letter e isn't a predefined value in Maple. To get e^5, you need to use exp(5).

The problem is that (unfortunately) Heaviside(a::algebraic) evaluates to something other than itself: It evaluates to Heaviside(a)! My preference would be that it return an error message. Perhaps this should be considered a bug of Heaviside. We can quickly look through the code showstat(Heaviside) and see where things go wrong. The argument a::algebraic passes through the type check in the proc line because an expression of the form a::b is of type algebraic! (I think that this should be considered the real bug.) Then between lines 23 and 24, the argument passes the type check linear(a). (This should also be considered a bug.) Then in line 30, the return value is set to Heaviside(a). Many other standard procedures, such as sin, return unevaluated when passed a::b.

All of the bugs mentioned above would be fixed if type(a::b, algebraic) returned false. According to ?type,algebraic, it should return false because `::` is not one of the 13 types listed, and a::b typechecks as false against all 13.

Now, turning to your patmatch command: patmatch(Heaviside(x), Heaviside(a)) returns false because the arguments aren't identical. There's no real pattern in the second argument because there's no ::. A perfect identity match is expected for any parts of the pattern for which there's no ::. This also explains why it returns true when you change a to x.

The difference between patmatch and typematch is that patmatch accepts as its second argument patterns which are far more complex than those allowed by typematch. The latter basically only allows type expressions prepended with name::. Examples:

patmatch(x+2, a::name + n::posint) returns true.
typematch(x+2, a::name + n::posint) returns an error message because name+posint isn't a valid type.
typematch(Heaviside(x), Heaviside(x)) returns an error message because x isn't a valid type.

I find Christian's explanation of the difference quite confusing and misleading, although it's technically correct, I guess.

If you use lprint on the results, you'll see that they are essentially the same. A 1-D Array whose indices start at 1 prettyprints as if it were a Vector, and 2-D Array both of whose indices start at 1 prettyprints as if it were a Matrix. Using lprint reveals the true nature of things.

Basically, prettyprinting allows almost anything to be displayed as if it were something else without changing the underlying value. If I wanted sin(1) to display as 42, I could write a one-line procedure to do that. Of course, prettyprinting is only useful when it shows some useful mathematical representation of the underlying object. Since a 1-D Array with indices starting at 1 is essentially a Vector, that's appropriate here.

Your code above the fsolve does not define, or even use at all, any variables named Eq1 or Eq2, yet you refer to them in the fsolve command.

See ?Statistics,Lowess. One of the examples shows doing an integration.

The basic command for this is ListTools:-Classify. But it returns the elements themselves rather than their position numbers. You need to pair each element each with its position number (that's the `[]`~(a, [$1..nops(a)]) below), Classify according to the first element (x-> x[1]) of each pair, and then extract the position numbers (x-> x[2]):

{entries(((x-> x[2])~)~(ListTools:-Classify(x-> x[1], `[]`~(a, [$1..nops(a)]))), nolist)};

     {{1}, {3}, {2, 4}}

If you require that the results be returned as lists and in the order that you specifed, that can be easily done.

By the way, is there some good reason why each element of your list a is itself a list? My code above doesn't care about that, but it makes me wonder whether I am missing some nuance of your problem.

Letting p be your polynomial, it can be done like this:

v:= indets(p, suffixed({x,y,z})):
coeffs(p, v, 'M'):
[op(sort(`+`(M), order= plex(ListTools:-Reverse([v[]])[]), descending))];

The pre-subscript and pre-superscript have no overall predefined meaning in Maple, although they may be given meaning by some packages. I suspect that even in these cases, this notation is only used for the display of the results and has no meaning computationally. For example, a pre-subscript is used in the prettyprinted display of hypergeometric functions when typesetting is set to extended:

interface(typesetting= extended);
hypergeom([a], [b], x);

You are free to assign to them any meaning that you want.

Here are procedures for extracting them:

PreSub:= (x::{name, name^anything})->
     if x::`^` then thisproc(op(1,x))
     elif x::indexed then thisproc(op(0,x))
     else parse(op([6,1], parse(substring(x, 2..))))
     end if
:
PreSuper:= (x::{name, name^anything})->
     if x::`^` then thisproc(op(1,x))
     elif x::indexed then thisproc(op(0,x))
     else parse(op([7,1], parse(substring(x, 2..))))
     end if
:

Please let me know if that gives you what you want. If you want them returned with their color intact, that's slightly different.

Use D:

g:= D(f);
g(2);

In the function f(x,t), x is the first variable, so the second derivative with respect to x is D[1,1](f). You have D[2](f), which means the first derivative with respect to the second variable. After correcting for this, you still have the problem that you have no initial conditions; you only have boundary conditions. One usually specifies that something special happens when t=0.

Functional iteration is done with @@, so you can make your plot with

plot([seq([k, nops((Y@@k)({}))], k= 1..20)], style= point, symbolsize= 24);

The speed of Y can be improved with a remember table. See ?remember.

Real programmers don't use untypeable variable names with silly hats on them.

I think that the point of the error message is that dsolve can't solve ODEs of arbitrary, unspecified differential order, although that point is sometimes made more explicit as in

dsolve(diff(y(x), [x$n]) = y(x), y(x));
Error, (in dsolve) unable to handle ODEs of undefined differential order

geom3d:-point~([A,B,C], [[4,5,5], [-9,4,7], [-3,-3,3]]):
geom3d:-line(L1, [A,B]):
geom3d:-line(L2, [C, [5,7,-4]]):
geom3d:-distance(L1,L2);

     (289/2315)*sqrt(2315)

Here's a conversion procedure:

IndicesToSubscripts:= e-> subsindets(
     e,
     'indexed',
     n-> cat(
          `if`(op(0,n)::'indexed', IndicesToSubscripts(op(0,n)), op(0,n)),
          __,
          `if`(hastype([op(n)], 'indexed'), IndicesToSubscripts~([op(n)]), [op(n)])[]
     )
):

Example use:

e:= x[1] + y[a][b[c]]:
IndicesToSubscripts(e);

(output suppressed)

lprint(%);

x__1+y__a__b__c

Ordinarily indets, subsindets, and evalindets (without the flat option) are inherently recursive, working their way through the expression tree, but indets doesn't seem to extract indices, so the recursion needs to be made explicit in my procedure above.

The command lprint will reveal the underlying structure of almost anything in Maple. So, use lprint(A).