Some hints: Part (a) and both parts of (b) can each be done with a single one-line rsolve command. For part (c), treat x as a continuous variable. Use several plot3d commands, each at a fixed value of n, with a and b as the independent variables. I haven't done this part of the problem yet, but I suggest that you first try logarithmic scaling for n: n=2, 4, 8, 16, .... Because of the sign-alternating terms, do a companion series of plots for odd n: 3, 5, 9, 17, .... The even and odd will not necessarily be much different. An animation or Explore (Markiyan's suggestion) may be appropriate. You don't have to explicitly use a z-transform or any other algorithm for any part of this problem; the rsolve does it all.

This is usually the easiest computational monotonicity check in Maple: If the function is differentiable and its derivative has no zeros (no roots), then the function is monotonic. (If its derivative does have a zero, the function may still be monotonic; it requires slightly more investigation: Check whether the sign of the derivative changes as it passes through the zero. If it doesn't change, then the function is monotonic.)

All your troubles are because frem only takes numeric arguments. Using unevaluation quotes to prevent frem from receiving a nonnumeric argument will only get you so far. What's needed is a symbolic equivalent to frem. Here it is:

Frem:= (x,y)-> x - y*floor(x/y+1/2);

And here is a worksheet using this that solves all your problems: plot, symbolic integration, numeric integration, and dsolve of a single ODE and of a pair of ODEs.

Download frem.mw

There are so many problems in your code. We'll need to work through them a few at a time. Let's start with the first line. It's clear from the code that you intend for f to be a procedure and x0 a numeric constant. We'll reduce future mistakes by declaring those types:

kokoko:= proc(f::procedure, x0::complexcons)

The local line is okay for now.

What's the purpose of p:= problemm? Is problemm supposed to be a symbolic constant? or a global variable? If it's a symbolic constant, you can make that clearer by using unevaluation quotes:

p:= 'problemm';

I notice that p is effectively never used in the rest of the program. So what's its purpose?

Next, I suppose that you want to evaluate the derivative of f at x0, and decide what to do next based on whether it's greater than 1. There's no need for variables d and e. Simply do

if evalf(D(f)(x0)) > 1 then ...

See how far you get with that advice, and then Reply here if you need more.

Extracting a numeric parameter from an error message is easy. In the worksheet below, I present a short and simple procedure to do it. I use Preben's parentheses-corrected version of your ODEs and his nontrivial initial conditions.

Download find_sing.mw

Below, I have solved the specific problem of finding the fourth root (over a finite field) of your original matrix. Before I generalize this into a procedure to find, where possible, any root of any matrix over any finite field, I'd like for you to confirm that this meets your needs, that it executes on your version of Maple, etc.

To create the worksheet below, I necessarily had to repeat the code from my previous two Answers to you. I apologize to all readers for the repetition. The last third of the worksheet is entirely new material.

Download Matrix_powers_finite_field.mw

Download frem.mw

Convert the overall list to a set, then convert the vectors to lists and then back to vectors. It can all be done with a single command like this:

`<|>`~(map(convert, {eq[]}, list));

I agree with Markiyan in that I know of no well-defined concept of a spanning tree for a directed graph, unless you mean a spanning tree (or forest) of the underlying undirected graph. Nonetheless, your procedure should return something interesting, even if it couldn't properly be called a spanning tree. My guess is that it'll return the maximal outward-branching tree that can be formed starting at the given vertex. This'll show all vertices reachable from the given vertex, which is inherently interesting.

I found four obvious errors in your code:

1. Replace assigned(visited[]) with assigned(visited[w]).
2. Replace Departures(G,v) with Departures(G,w).
3. In the final return, replace edges with convert(edges, 'set').
   
4. In procedures, you can't rely on packages being loaded, nor is it safe to use with in a procedure. So, package commands should be fully qualified (e.g. GraphTheory:-Graph) or the package name should be declared in a uses clause in the header of the procedure.

Furthermore, indent your code! It'll make errors easier to find. The following is my indenting style. I'm not saying that you should use my style, but that you should have a style.

DiSpanningTree:= proc(G,v)
uses GT= GraphTheory;
local
     comp:= Array([]), edges:= Array([]), visited:= table(),
     recurse:= proc(w)
     local z;
          if assigned(visited[w]) then return false end if;
          comp(numelems(comp)+1):= w;
          visited[w]:= true;
          for z in GT:-Departures(G,w) do
               if recurse(z) then edges(numelems(edges)+1):= [w,z] end if
          end do;
          true
     end proc
;
     recurse(v);
     GT:-Graph(convert(comp,'list'),convert(edges,'set'))
end proc;

I haven't tested the above code; I've only corrected the four obvious errors. 

Those limits are not specific to a GUI; they're set in the kernel with the kernelopts command. For example

kernelopts(cpulimit= 1*Unit(hour)):
kernelopts(datalimit= 1*Unit(gibibyte)):

See ?kernelopts.

The procedure `PDEtools/NumerDenom` is fairly simple, and you may understand it just by reading its code, which can be done via

showstat(`PDEtools/NumerDenom`)

To find out where it is being called from, give the commands

debug(`PDEtools/NumerDenom`);
stopat(`PDEtools/NumerDenom`);

Then issue the command that causes the error. When the debugger starts, give it the command

showstack

My guess is that it'll be very difficult to tell when this kind of coefficient blowup will occur, and even more difficult to tell whether isolate will work better than solve. So I think that what's needed is a way to "normalize" the coefficients after the blowup. My procedure balance below handles this. There're probably cases where it won't work, but this is the kind of thing that's used on an ad hoc basis.

Download balance.mw

By the way, I corrected your Eq1: It had a "naked" y1 which I changed to y1(t).

How about 12 seconds? It's better than your current 32 seconds. Use this:

A:= ImportMatrix(
     "/Imp34462 14.txt",
     source= delimited, delimiter= ";", datatype= float[8]
):

eqn:= diff(y(t),t) = -.25*y(t):
init:= y(0) = 5:
sol:= dsolve({eqn, init}, {y(t)}, numeric):
p:= plots:-odeplot(sol, [t, y(t)], t= 0..50, colour = red):
A:= select(p-> p[2] > 1.5, convert(op([1,1], p), listlist));

Okay, I understand your polynomial-to-integer encoding scheme now. The command to extend an already-extended finite field is Primfield. So, in the worksheet below, I extract the root of your quadratic irreducible in GF(2^8) and give it a representation in GF(2^16). Then I get the other root in the new field.

Download Primfield.mw