It can be done like this, for example. This code does the same thing as the code that you posted above.

restart:
N := 10; #number of oscillators
K := 100; #number of times process is run
phi := 5; #bump given to oscillators when one fires
alpha := .5; #constant that affects extent to which size of firing populations affects bump
R:= rand(0..100); #100 should be a named constant
S := Array([seq(Record[packed]('val'= R(), 'sensitivity'= `?`, 'strength'= `?`), j= 1..N)]);

to K do
     t:= 100 - max(seq(S[j][val], j= 1..N));

     mu:= 0;
     for j from 1 to N do
          S[j][val]:= S[j][val] + t + phi;
          if S[j][val] > 99 then S[j][val]:= 0 end if;
          if S[j][val] = 0 then mu:= mu+1 end if
     end do;

     for j from 1 to N do
          if S[j]<>0 then
               S[j][val]:= S[j][val] + exp(alpha*mu);
               if S[j][val] > 99 then S[j][val]:= 0 end if
          end if
     end do
end do;

When you want to add a finite specific number of terms (rather than perform a symbolic summation) you should use add instead of sum. Then you will get the correct answer. By using sum, you are causing the premature evaluation of 0^(2*k), which evaluates to zero,  k being initially unknown. With add, the terms are not evaluated until the values of k are substituted, and then 0^0 evaluates to 1.

This issue has been discussed on Maple forums for decades.

Like your factor issue of today, there is also a workaround for this problem using frontend. This time we do freeze I, which frontend does by default. To freeze it means to treat it as just a name. In the factor issue, we froze the Pi (frontend froze it by default) but not the I.

frontend(convert, [[x, [I*x-1, 1]], parfrac, x], [{`+`,`*`,list}]);

Here is how to work around this issue with frontend:

frontend(factor, [Pi*(x^2+1), {I}], [{`+`, `*`}, {I}]);

I can't come up with logical argument about why things are the way they are with factor, except to say that perhaps it was too difficult for it to be designed otherwise, and that the designers knew that these idiosyncracies could be circumvented with frontend.

f5:= (a,b,c,d,e)-> a^2+b^2+c^2+d^2+e^2:
f3:= (ab, cd, e)-> ab[1]^2 + ab[2]^2 + cd[1]^2 + cd[2]^2 + e^2:
f5(1,2,3,4,5);
                                                   55
f3([1,2], [3,4], 5);
                                      55

There is a Maple procedure to automate this: codegen:-packparams:

codegen:-packparams(f5, [a,b,c], ABC);

My method, similar to Acer's, takes 23 seconds. Note that I selected a different NAG integration routine, appropriate for infinite intervals, and set the upper limit to infinity (because I assumed that that was your original intention). Note the capital-I Int. That's the key to getting numeric integration.

with(plots):
z:= 2*Int((sin(2*y)-sin(y))*cos(y*x)*exp(-y^2*t)/y, y = 0 .. infinity, method= _d01amc)/Pi;
animate(plot, [z, x = 0 .. 10, y= -.1..2, gridlines= false], t = 0 .. 1, frames = 100);

I see numerous syntax errors, and I don't know why you can't find them yourself at this point.

1. There should be a semicolon, not a comma, after local bb
2. i also should be declared local
3. There should be no = after i in the for clause
4. You need a space before end if
5. You have an extra colon in y::= x[i]^2

Fix those, then I'll help you with the rest.

You can't use the word error as a name in Maple code. (Well, you can't do it directly at least.) Use err instead.

You're making this unnecessarily complicated. Just use dsolve and plot the function that it gives you for each value of b:

restart:
ODE:= b-> 2*diff(y(t),t$2) + b*diff(y(t),t) + 9*y(t) = 0:
ICs:= y(0)=0, D(y)(0) = -3:
Y:= b-> rhs(dsolve({ODE(b), ICs})):
b||(1..3):= 1, sqrt(72), 9:
plot(['Y(b||k)' $ k= 1..3], t= 0..2*Pi, legend= ['b = b||k' $ k= 1..3]);

Your syntax for a Matrix constructor in HomRot is completely wrong. It should be

HomRot:= theta->
     < < cos(theta)  | sin(theta) | 0 >,
       < -sin(theta)  | cos(theta) | 0 >,
       < 0               | 0              | 1 >
     >;

There are a few other syntaxes available also. Without seeing your code for Trans and HomSquare, I can't help you further.

Do you intend for the function to be zero outside the ranges that you defined in the piecewise? One thing that you can do is simply add a plot range:

plot(piecewise(0 <= t and t < 2, 2-t, 2 <= t and t <= 3, 2*t-4), t= 0..6, axes= boxed);

You can select individual curves in a plot with the mouse. Then right click for the context menu. Then select the Line submenu.

Programmatically, you can do something like this:

plot([x, x^2], x= 0..2, linestyle= [solid, dash]);

In your second worksheet there is a procedure FiveSpeedGearBox_R which contains the two lines

eq:= piecewise(ig=1,i[1],ig=2, i[2],ig=3,i[3],ig=4,i[4],ig=5,i[5],1);
return eq(ig);

The expression eq(ig) is gibberish. Unfortunately, Maple does not recognize it as such and lets you run with it. A piecewise expression is not a procedure---it does not take an argument. Replace these two lines with the single line

return piecewise(ig=1,i[1],ig=2, i[2],ig=3,i[3],ig=4,i[4],ig=5,i[5],1);

After making that change, the solve runs for about 90 minutes and returns a solution without error or warning. That solution is five screens "wide" by 56 screens "tall". Here is the executed worksheet:

withGB.mw

You can use a recursive procedure.

X:= proc(Xo,Ro,n)
option remember;
     if not n::nonnegint then return 'procname'(args) end if;
     if n=0 then return Xo end if;
     Ro*thisproc(Xo,Ro,n-1)/(1+thisproc(Xo,Ro,n-1))^4
end proc:

BTW, I corrected your spelling of Hassell.

You must use N:= floor(a/h) or trunc(a/h). If you use round(a/h) then there's a risk that your x's will get larger than a. Note that trunc is semantically equivalent to floor for nonnegative numeric arguments, but trunc is simpler and faster.