On the other hand, 'them' is indefinite, it could refer to Mr Brown, and his two children.  Assuming that Mr Brown is male, we then know nothing about the sex of the children.

You can shorten that to

M := n -> Matrix( [seq( [f,g,h](i), i=1..n )] ):

For the really lazy typist, you can do

M := n -> Matrix([f,g,h]~([seq](1..n))):

Alternatively, you can use a Matrix initializer function

M := n -> Matrix(n,3,(i,j)->[f,g,h][j](i));

You can shorten that to

M := n -> Matrix( [seq( [f,g,h](i), i=1..n )] ):

For the really lazy typist, you can do

M := n -> Matrix([f,g,h]~([seq](1..n))):

Alternatively, you can use a Matrix initializer function

M := n -> Matrix(n,3,(i,j)->[f,g,h][j](i));

Quite amusing.

That reminds me.  Why doesn't Maple have a command to convert from its base representation (list of integer in reverse order) back to an integer?  It isn't hard to write one, but one is invariably needed when playing with bases, so it really should be provided.  I'll suggest that

convert( [1,2,3], base, 4, decimal)

should do just that, returning 57.

@acer That seems esoteric, though an inplace conversion is handy. Clearer, at least to me, is

V:= Array(1..5, i-> Matrix(P[.., .., i]));

@acer That seems esoteric, though an inplace conversion is handy. Clearer, at least to me, is

V:= Array(1..5, i-> Matrix(P[.., .., i]));

@Carl Love You are correct, the linked-list version does use allocate less memory. I was sloppy doing the original comparison, never a good idea when comparing memory usage, which can be delicate.

Correction Now I'm less sure.  It should allocate less memory, but the two appear to allocate essentially the same amount.  Hmm. 

@Carl Love You are correct, the linked-list version does use allocate less memory. I was sloppy doing the original comparison, never a good idea when comparing memory usage, which can be delicate.

Correction Now I'm less sure.  It should allocate less memory, but the two appear to allocate essentially the same amount.  Hmm. 

Nice alternative approach.  Here's something to ponder. Rather than generating a list for each path, suppose we generated a linked-list. Intuitively that should require less allocated memory because each new path requires only a two element list (the existing path is reused), rather than a k-element list.  It does, in fact, allocate less, the comparing the two can be a bit tricky.

AllPaths := proc(G::GraphTheory:-Graph
                 , maxlength::nonnegint:= GraphTheory:-NumberOfVertices(G)
                )
    # Returns a table R such that R[k] is a list of all directed paths
    # of length k in G, where k ranges from 0 to maxlength. G can be
    # directed or undirected.  Each path is represented as a
    # linked-list of vertices, the first element containing the last
    # vertex in a path.  The algorithm is breadth-first search.
uses GT = GraphTheory;
local k  # current length
    , p  # current path
    , v  # current vertex
    , V := GT:-Vertices(G)  # constant
    , E := table(V =~ (`{}`@op)~ (GT:-Departures(G)))  # constant table of edges
    , R := Array(0..maxlength);
    ;
    R[0] := `[]`~(V);
    for k to maxlength do
        # For each path of length k-1, make all possible extensions.

        R[k] := [seq(seq(`if`(has(p,v)
                              , NULL
                              , [v,p]
                             )
                         , v = E[p[1]])
                     , p = R[k-1])];
    end do;
    R;
end proc:

Correction:

I removed the call to MakePath; it was a vestige of an initial design.

Further Correction: restored missing angle brackets.  Also (later) fixed initialization of R).

Nice alternative approach.  Here's something to ponder. Rather than generating a list for each path, suppose we generated a linked-list. Intuitively that should require less allocated memory because each new path requires only a two element list (the existing path is reused), rather than a k-element list.  It does, in fact, allocate less, the comparing the two can be a bit tricky.

AllPaths := proc(G::GraphTheory:-Graph
                 , maxlength::nonnegint:= GraphTheory:-NumberOfVertices(G)
                )
    # Returns a table R such that R[k] is a list of all directed paths
    # of length k in G, where k ranges from 0 to maxlength. G can be
    # directed or undirected.  Each path is represented as a
    # linked-list of vertices, the first element containing the last
    # vertex in a path.  The algorithm is breadth-first search.
uses GT = GraphTheory;
local k  # current length
    , p  # current path
    , v  # current vertex
    , V := GT:-Vertices(G)  # constant
    , E := table(V =~ (`{}`@op)~ (GT:-Departures(G)))  # constant table of edges
    , R := Array(0..maxlength);
    ;
    R[0] := `[]`~(V);
    for k to maxlength do
        # For each path of length k-1, make all possible extensions.

        R[k] := [seq(seq(`if`(has(p,v)
                              , NULL
                              , [v,p]
                             )
                         , v = E[p[1]])
                     , p = R[k-1])];
    end do;
    R;
end proc:

Correction:

I removed the call to MakePath; it was a vestige of an initial design.

Further Correction: restored missing angle brackets.  Also (later) fixed initialization of R).

@Carl Love Ah, that helps.  My guess, and its only a guess because I'm not a GUI developer, is that an integer is greater than kernelopts(maximmediate).  To find the culprit do

S := ToInert(eval(soltn)):
mx := kernelopts('maximmediate'):
select(`>`, FromInert~(indets(S, _Inert_INTPOS(anything))), +mx);
                  {18446884586911901406}
select(`<`, FromInert~(indets(S, _Inert_INTNEG(anything))), -mx);
                  {}

@Carl Love Ah, that helps.  My guess, and its only a guess because I'm not a GUI developer, is that an integer is greater than kernelopts(maximmediate).  To find the culprit do

S := ToInert(eval(soltn)):
mx := kernelopts('maximmediate'):
select(`>`, FromInert~(indets(S, _Inert_INTPOS(anything))), +mx);
                  {18446884586911901406}
select(`<`, FromInert~(indets(S, _Inert_INTNEG(anything))), -mx);
                  {}

@cosmicstring Remove the evalc. That "simplifies" evalc(Re(R1(r))) to R1(r).  You just want Re(R1(r)). 

@cosmicstring Remove the evalc. That "simplifies" evalc(Re(R1(r))) to R1(r).  You just want Re(R1(r)). 

The logical expressions cond1 and cond2 and `and`(cond1,cond2) are not completely equivalent.  The difference is that all the operands of `and` are always evaluated. For example,

f := proc() print(hello); false end proc:
f() and f();
                                                      hello

                                                      false
`and`(f(),f());
                                                      hello

                                                      hello

                                                      false