@mmcdara Your example only works for a coincidental reason: 3 is the largest index. That it's the index of the largest entry isn't being considered. 

But something workable could be made by using the pairs option to indices or entries.

@ Vote up. I wanted to let you know two things for your assuming clause. The first is that it can be shortened to (m, k, a, t) >~ 0. The second is that and is never needed: The commas imply and.

Also, it should be pointed out that evalc assumes that all variables are real, and that's likely why it helps in this case. You probably already know this, but the OP may not.

@sand15 The OP did say that the transform is with respect to x. 

My Answer initially had x and t reversed when showing that diff@fourier was already implemented. But that had no effect on my implementation of fourier@diff.

@Thomas Richard That's not a screenshot. It's the hideous result of using the Maple Math tool in the MaplePrimes editor. It's the one immediately to the right of the upload arrow.

@imparter You posted a Question about 10 days ago asking about solving a finite difference scheme. That's the way to do this.

@Gabriel Barcellos 

Expressions are composed of operands contained in something I'll call a container. In some simple cases, it may not seem like a "container" in the usual sense of the word, but that's the best word that I can come up with for this elementary discussion. There are only a few fundamental types for these containers, and it'll only be the type of the container rather than the container itself that we'll need to consider.

A simple example is a list, for example, L:= [3, x+y, 7]. It's operands are the elements. They command op will return them:

op(L);
               3, x + y, 7 

In most cases, the type of container is returned by op(0, ...):

op(0, L);
                list

The fundamental container types that should be understood for this particular Question thread are `+`, `*`, `^`, and function.

Type `+`:

A:= x + y - z:  op(A);
             x, y, -z
op(0,  A);
              `+`

Expressions whose primary operation is subtraction of 2 or more operands are also considered to be type `+`. Because of algebraic associativity, `+` expressions can have 2 or more operands. 

Type `*`:

P:= -x*y/z:  op(P);
             -1, x, y, 1/z
op(0, P);
             `*`

Note that the unary negation of the expression introduces -1 as a distinct operand. Expressions whose primary operation is division are also type `*` unless their numerator is 1 or their numerator and denominator are both integers. Because of associativity, `*` expressions can have 2 or more operands.

Type function:

F:= Tanh(x, y, z):  #Tanh is just made up for this example.
op(F);
              x, y, z 
op(0, F);
              Tanh

So, operand 0 of a function is the function's name rather than the literal word function.

To be continued...

Do you want to use both the slash ( / ) and the other division symbol as input in the same Maple session? If so, then do you want them to have some subtle difference in interpretation, such as precedence? 

@imparter The error is due to what I said in my Answer: Maple's stock numeric PDE solver can only handle 2 independent variables. You have 3.

@C_R I promoted your excellent investigation to Answer so that I could vote it up. 

I vote up for the Question also; almost every Question from @nm gets a vote up from me.

@nm The difference between subs and eval is that eval tries to be wary of performing mathematically invalid operations, whereas subs explicitly and intentionally ignores mathematical subtleties and operates purely syntactically. The n in the Sum is a bound variable, and changing subexpressions that contain bound variables is something that can be mathematically dubious. 

The significant difference here is NOT that subs does not do evaluations (although that is indeed true); it's that eval tries to NOT do mathematically invalid substitutions.

Note that I'm not saying that this particular operation is mathematically invalid! But messing with bound variables is something that eval is rightfully wary about.  

Although a multiple subsindets or evalindets isn't needed in this particular case, there are times when it is needed, and the syntax (described at ?subsindets) allows for something shorter than what you had. Like this:

subsindets(expr, specfunc(Sum), subsindets, indexed, f-> b[op(f)])

This can be extended to any number of subsindets and/or evalindets, and they can be mixed.

@Carl Love I just read your ending part about the local and global a. You can just use 
subs(a= b, ...) and it'll only change the local a. Like this:

MySum:= (A, b::name, r)->
local 
    a,
    S:= Sum(x^(_n+r)*a[_n]*(_n+r)*(_n+r-1)+a[_n-1]+3*A*x^10, _n = 0 .. infinity)
;
    subs(a= b, S)
:
MySum(a, B, r); 

@nm Okay, I get your point. Yes, it could detect this anomaly and simply refuse to plot some of the arrows if need be. And this should be implemented.

@nm Note that the arrows extend beyond the solution curve to the y boundaries, into the complex-valued part of the range. If the arrows are straight, that's easy to do (although not very accurate): It uses the arrow's base point as an initial condition, does a one-step solution of the ODE to get a slope, and draws a straight line segment. But for curved arrows, it needs to solve the ODE over the length of the arrow, for every arrow.

@Gabriel Barcellos 

Both Acer's Comment and my code adjustment only make any difference when the expression has only 1 term. In the jargon of computer programmers, we call that a "corner case". Note that the _z doesn't occur in A01, and, of course, it doesn't have any functions. Thus it can't change the desired answer; it merely prevents you from getting the undesired answer when A01 has only 1 term.

I can give you a deeper explanation if you want.