Are you sure that is the error you receive?  Something else is going on. Try calling the code with f('result', 2); 

Use the builtin table index function antisymmetric.

T := table('antisymmetric'):
T[1,2];
            T[1,2]
T[2,1];
           -T[1,2]
T[1,1]; 
               0

That just indicates the name of the procedure in which the error was generated (more likely trapped).  What was the actual error message?

You can double the speed by removing all the calls to evalhf and wrap the entire call to the procedure in one:

evalhf(GBIKF012(...));

The problem is that you have not initialized Aplus to anything.  When Maple attempts to evaluate

Aplus := Aplus + 2*m;

it recursives indefinitely (think about it).  Try first assigning 0 to Aplus:

Aplus := 0;

I haven't tested your code, but one thing you should not be doing is inserting ?with statements into the body of a procedure. That does not work. They must be at top-level. To get the equivalent effect inside a procedure, use the ?uses statement:

plottingmyarray := proc()
uses StringTools, plots;
    ...
end proc:

A second problem is that the first call to plot will not produce output. To do that, wrap it in a print statement:

print(plot(...));

If the partition is decomposable, which is generally not the case, the following computes it

map[3](select,`subset`,P1 minus P2, P2 minus P1);

No claims as to the efficiency of this

One way to do this using the standard components is to use a reset integrator with its input driven by a pulse train and its reset input triggered when the pulse train goes low.  Here is an example, sawtooth.msim

One possibility is to insert a translational brake between the position driver and the connection to the prismatic joint. The housing of the brake is connected to the prismatic 1D input, while one of the flanged is connected to the position driver.  With the brake open, the positional driver has no effect, with it closed, it controls the position.

You might be better off passing the 'output=listprocedure' option to ?dsolve.  For example

deq := {diff(x(t),t,t)=1, x(0)=0,D(x)(0)=1}: 
integ := dsolve(deq,numeric,output=listprocedure):
xsol := eval(x(t), integ):
map(xsol, <0,1,2,3>);

The problem is that tables and procedures evaluate to names, and a name is of type polynom.  You could do

type(eval(T),polynom);
                                     false

however, the call to eval can be expensive. A better way is

type(T, 'And(polynom,Not(last_name_eval))');
                                     false

Note that your example using polynom(prime) is consistent; the prime refers to the coefficient, and the coefficient of T is 1, which is not prime.

You can do

FooBar := proc( fs::seq(And(polynom,Not(last_name_eval))), T::{procedure,table} )

add(x,x=A);

Musing:

Just as seq(i, i=1..4) can be shortened to seq(1..4), it might be neat, but probably not worthwhile, if the addition could be shortened to add(A).

The data structure you are asking for, a list of matrices, some of them repeated, is strange, though there may be a good, if unexplained, reason for it. The strangeness is that if you change an element in one of the repeated matrices, the corresponding element changes in its twins. Presumably that is the intent.

A comment on the suggested techique (from the link).  ?CurveFitting[PolynomialInterpolation] fits a polynomial of order n-1 to n points.  That is why the instructor's example only includes four of the 10 data points.  A better way is to use ?CurveFitting[LeastSquares], which allows you to specify the expression to fit to. Thus

LeastSquares(xpts, ypts, x, add(a[k]*x^k, k=0..3));

will fit a cubic polynomial, using all the data

The warning "nags" from the flattener, "no value specified for parameter ... " obscure a real error.  To see the actual error, click the "Display the message console" icon on the bottom toolbar, it looks like a small console (with horizontal lines representing lines of text).  You will then see

Simulation problem: maximum number of event iterations reached (100) at t=.11939218e-2

I haven't looked into this closely, but have dealt with similar configurations. The probable cause is the switching of the diodes.  As a simple but effective workaround, attach a large resistor, say 1Mohm, from ground to the left side of the inductor.