The following code is equivalent to your code except that the recursive procedure GoDownTree returns a sequence. Therefore, each level of recursion doubles the length of that sequence. You are correct that print is never a good way for any procedure to return its value, let alone a recursive procedure.

istZweirpotenz:= (n::posint)-> evalb(n = Scale2(1, ilog2(n))):

SubProdTree:= proc(n::satisfies(istZweirpotenz), x::name, u::And(list, satisfies(u-> nops(u)=n)))
local k:= ilog2(n), j, i, M::table(polynom(integer, x)), leftList, rightList, kList;
   for j to n do M[0, j-1]:= x-u[j] od;
   for kList from 0 to k do
       leftList[0, kList]:= M[0, 2*kList];
       rightList[0, kList]:= M[0, 2*kList+1]
   od;
   for i to k do
      for j from 0 to 2^(k-i)-1 do M[i,j]:= M[i-1, 2*j]*M[i-1, 2*j+1] od;
      for kList from 0 to 2^(k-i-1)-1 do
         leftList[i, kList]:= [leftList[i-1, 2*kList], rightList[i-1, 2*kList], M[i, 2*kList]];
         rightList[i, kList]:= [leftList[i-1, 2*kList+1], rightList[i-1, 2*kList+1], M[i, 2*kList+1]]
      od
   od;
   ListTools:-Flatten([leftList[k-1, 0], rightList[k-1, 0], M[k,0]])
end proc:         

GoDownTree:= (f::polynom, n::satisfies(istZweirpotenz), x::name, l::list, p::prime)->
   if n = 1 then f 
   else 
      thisproc(evala(Rem(f, l[n-1], x) mod p), n/2, x, l[..n-1], p),
      thisproc(evala(Rem(f, l[2*n-2], x) mod p), n/2, x, l[n..2*n-2], p)
   fi
:
FastEval:= (f::polynom, n::satisfies(istZweirpotenz), x::name, p::prime, u::list)->
   GoDownTree(f, n, x, SubProdTree(n, x, u), p)
:

FastEval(x^2+x+1, 8, x, 11, [$1..8]);

      3, 7, 2, 10, 9, 10, 2, 7

I note that your code did not make any use of the field GF(11,2). So, my code doesn't either, as I said my code is equivalent to yours. So, the computations are done over GF(11,1), but I don't know if that was your intention. The evala command does nothing in this example. As far as I know, there is never a reason to use both evala and mod, but I am not sure about that.

Pay close attention to the ways that I changed your code, especially:

1. ilog2(n) is equivalent to floor(log[2](n)) when n is a positive integer, but it is many times faster.
2. Procedures usually should give an error when they are given invalid input, not return false.
3. Recursive procedures should almost always return values.
4. Unassigned global names (x in this case) should be passed in rather than having the procedure just assume that they're unassigned.
5. Do not use the with command to load packages for use in procedures.

The issue is the lack of a space character after &t, as pointed out by Torre. Whether you use a space before &t is unimportant.

The code layout on those online help pages looks like some automatically generated crap, and it's easy to see how they'd lead you to make such an error. I recommend that you always compare those pages with the in-program help, in this case ?DifferentialGeometry,Tensor,KillingVectors. For additional clarity, press F5 so that the code of the help page examples will be displayed in a monospaced font (if it isn't already thus displayed).

I'm not aware of any situation in Maple where an uninterupted sequence of alphabetic letters is interpretted as multiple symbols. So, the way that you've coded it, Maple isn't even aware that you're trying to use &t as a neutral operator; rather, it thinks that you're trying to use &tdx as a neutral operator, which is invalid because it's not followed by an operand.

@mmcdara Yes, what you ask for is essentially possible if you're willing to accept an equivalent of "indeterminate" instead of undefined.

solve({a*b = a*c}, b, parametric);

      piecewise(a = 0, [{b = b}], a <> 0, [{b = c}])

It's very rare (if at all) that much useful can be done in Maple by assuming a one-point inequality. And solve is quite resistant to all assumptions, although there are sometimes ways around that.  

The restart command should always be placed alone in its own execution group. The problems that can happen if you don't do this are subtle, possibly intermittent, and difficult to specify precisely because they involve synchronization between separate processes (in this case, the mathematical/computational "kernel" process and the user-interface "GUI" process). Settings of the interface command are particularly sensitive to this because they are more-or-less commands to the GUI; whereas the vast, vast majority of Maple commands are to the kernel.

The help at ?restart is not absolutely clear about this point, which is something that I've complained about here several times over the years. That help currently (Maple 2018) says

• It must be executed in a separate prompt (or line) from all other commands, since all commands in a prompt are passed to the kernel at once; entering other commands in the prompt could cause unexpected results.

It should say "separate execution group" as well, because a separate prompt or line is not necessarily a separate execution group.

That sentence has been rewritten, perhaps in response to one of my complaints. It used to just mention separate lines rather than prompts.

Considering the huge number of times that problems caused by un-isolated restart have been reported here, that sentence should be highlighted and raised from its current position (which is the 8th paragraph under Description).

The word gradient is usually only used for the vector field of partial derivatives of a scalar function, i.e., a function from R^n to R^1 (with the gradient thus being a function from R^n to R^n). I think of it as the derivative of the scalar function. A vector field is a function from R^n to R^m, and the analogous derivative concept is the jacobian matrix, a function from R^n to R^(m x n). The Maple command for it is VectorCalculus:-Jacobian.

As far as I'm concerned, the distinction between a gradient vector and a jacobian matrix is purely syntactic, and the world would be better off if they were both simply called "the derivative".

The distinction between space dimensions and time dimensions isn't relevant to these concepts.

The procedure plot is not threadsafe (see ?threadsafe); no doubt it writes to numerous global variables. Try Grid:-Seq instead. I assume that in your actual application, each frame will take longer to generate. Otherwise, the overhead of Grid is not worth it.

Many people are under the false impression that any program can be run on multiple processors and thereby have its real run time reduced. This is not true of Maple or any other software, mathematical or otherwise. In order for an algorithm to benefit from multiprocessing, it must be capable of being divided into smaller tasks that can be done (at least somewhat) independently. The controlling program must carefully "outsource" the work to the various processors and combine the results. Maple provides two packages for multiprocessing: Grid and Threads. Threads is faster and uses less memory, but it can only be used when the sub tasks can safely share global memory with each other (i.e., they can't overwrite each other's intermediate computations).  For Maple, this is a severe restriction, and Threads cannot be used for most symbolic computations. Grid runs each sub task in its own memory area.

Fabio's procedure seems excessively complicated for the job, although I may not understand some of its functionality. So here's another procedure for pulling out scalar factors from a Matrix (or any rtable):

RtableScalarFactor:= (M::rtable)-> 
   (F-> `%*`(F, M/~F))(foldl(gcd, seq(numer~(M)))/foldl(lcm, seq(denom~(M))))
:

Do

map2(op, 1, factors(f)[2]);

If you want to do that over a finite field, do

map2(op, 1, (Factors(f) mod p)[2]);

where p is the characteristic. 

In either case, these commands will attempt to factor the factors. If you want to avoid this added expense (for example, because you already know that they're irreducible), a different command can be used; let me know.

I think that you may be confused by the fact that Maple is not displaying the result of every computation while it is doing that computation. Nonetheless, it is silently doing them and storing the results in f. Usually, the line-by-line results are only useful for debugging and all the user really wants is the final output. To see the final f in a neat tabular format, at the end of your code do

interface(rtablesize= max(N+1,M+1)):
Matrix((N+1,M+1), ()-> evalf[4](`?[]`(f, [args]-~1)));

If these are not the values that you're expecting, let me know. If you do want to see the results from the inner loop as they are being computed line-by-line, there are several ways to do that; let me know.

If your ultimate goal is solving a Black-Scholes (or similar) stochastic PDE without coding all the nitty-gritty computations yourself, see Maple's Finance package (?Finance).

All algebraic grouping in Maple is done with round parentheses ( ), not square brackets [ ]. No matter how deeply they're nested, they must be parentheses. Since the square brackets can be used for a variety of other valid purposes, they aren't usually flagged with an error when they're inappropriately used for algebraic grouping.

I'm not guaranteeing that correcting the brackets will get you to the final answer. Rather, I'm telling you that you must correct the brackets regardless. If you then still cannot get the final answer, post a Reply and someone will look deeper into it.

@José Goulart 

Regarding your "just wondering why it's so hard to rewrite expressions like that": For any operation, you need to tell Maple whether it should perform the operation or simply represent it inertly. Otherwise, how could it know? If the default action were to represent it inertly, then you'd just as well be saying "just wondering why it's so hard to to get Maple to expand products automatically." It's actually not that hard: Almost every operation has an inert form that can be made active with command value. The inert form uses % prepended to the operator.

restart;
interface(imaginaryunit= IU): #Make it any symbol other than I.
Ke:= (2*I*E/l^3) %* #Inert scalar multiplication
   <6,   3*l,   -6,   3*l;
    3*l, 2*l^2, -3*l, l^2;
    -6, -3*l,   6,    -3*l;
    3*l, l^2,   -3*l, 2*l^2
   >;

#When you want to expand the multiplication, use value:
value(Ke);

The above works in 1D input (aka Maple Input) in Maple 2018. I don't know about 2D Input. If it doesn't work for you, let me know, and I'll give you another form of the %* operator that's just a few more characters to type.

If eqs is a system of rational-function equations, as is the case here, then the simple command (numer@(lhs-rhs))~(eqs) will reduce it to an equivalent polynomial system. That alone is likely to give a boost to most solvers. If the system is equivalent to a linear system, as is the case here, then it's very likely (although not 100% guaranteed) that those polynomials will be linear. This will almost certainly improve the performance of any solver. Thus:

eqs:= {(T[1]-T[0])/(10000-T[1]+T[0]) = -2.000000000,
        (T[2]-T[0])/(20000-T[2]+T[0]) = 0,
        (T[3]-T[0])/(50000-T[3]+T[0]) = 50,
        .1*T[0]+.3*T[1]+.55*T[2]+0.5e-1*T[3]-.5 = 0}:
Sol:= fsolve((numer@(lhs-rhs))~(eqs));
        Sol := {T[0] = -8450.48039, T[1] = 11549.51961, T[2] = -8450.48039, T[3] = 40569.12746}
To be rigorous, we must verify that the solution works in the original equations because there is a
possibility of a 0/0-type undefined, which'd be flagged with a divide-by-zero error during the 
verification.
eval(eqs, Sol);
      {-2.000000000 = -2.000000000, 0. = 0, 0.000003 = 0, 50.00000036 = 50}

@Rariusz You need to translate the phrases "time", "input signal", "position of rotor", and "speed of rotor" into the variable names that you've used in the code. My guesses would be time = t, input signal = V, position of rotor = theta. I don't know about "speed of rotor"; perhaps that is diff(theta(t), t).

If V is a function of t, then V can't be used in a parameters option to dsolve. The syntax will allow it, but the results will be meaningless. You need to construct a function to interpolate V. This function can be symbolic or purely numeric. If it's purely numeric, than you'll need to declare it with dsolve's known option.

Your parameters should be [J, b, k, R, L]. These variables should not be assigned values prior to the dsolve call. By using Statistics:-Fit with procedure-form input and using the given values as initial values for these five variables, you can fit the parameters to the data in your file.

Unlike its ancestral language Algol, Maple's syntax doesn't allow a for-do statement in place of an expression sequence. Instead, use the seq command to create expression sequences inline. Replace your

for a in 'solve(diff(func, x) = slp, x)' do 'MMLV1'='MathML[Export]('y'=Tangent(func,x=a))' end do

with

seq('MMLV1'='MathML[Export]('y'=Tangent(func,x=a))', a= solve(diff(func, x) = slp, x))

You'll also need to adjust the unevaluation quotes, but I don't know enough about Maplets to fully correct them.