Maple's Iterator package is precisely made for this purpose: to generate combinatorial objects one-by-one so that they can be used in a loop without needing the entire list of them stored in memory. For example:

n:= 5: k:= 3:
for C in Iterator:-Combination(n,k) do
    print({seq}(C+~1))
od;
                           {1, 2, 3}
                           {1, 2, 4}
                           {1, 3, 4}
                           {2, 3, 4}
                           {1, 2, 5}
                           {1, 3, 5}
                           {2, 3, 5}
                           {1, 4, 5}
                           {2, 4, 5}
                           {3, 4, 5}

The in clause in the for-do loop header hides the fact that the objects are being generated one-by-one (per loop iteration) rather than as a container (list, sequence, etc.). 

Over the years, I have extensively tested the efficiency of various iteration commands in Maple: for-do, seq, map, etc. There is no significant difference between for and the others. It has a totally undeserved bad reputation for inefficiency. That reputation may be due the fact that there is a very inefficient operation which is unfortunately very common among newbies, and is done with do loops: building a sequence, list, or set one element per loop iteration. The inefficiency is specific to those three container types; building tables or arrays per loop iteration works fine.

The try ... catch statement is the way. In the following example, we predict that we'll face division-by-zero errors, but there's no need to tell Maple that. In other words, there's no need to put any string after the catch. The next statement means to continue with the next iteration of the loop.

R:= rand(-9..9):
randomize(1):
[to 9 do 1/R() od];
Error, numeric exception: division by zero
randomize(1): #to generate the same random numbers
[to 9 do try 1/R() catch: next end try od];
                  [-1  1  1      1  -1  1  -1]
                  [--, -, -, -1, -, --, -, --]
                  [4   2  3      2  4   6  9 ]

Note that the output list has 8 entries, not 9, indicating that one zero was skipped.

The above example is intended for 1D input (aka Maple Input) only.

sin(x)/cos(y) is not equal to any simple expression of tangent.

This (MaplePrimes) is a public forum, not an official place for customer support. (Although one can usually obtain excellent unofficial support here.) No forum---whether it be a paper periodical, a book, a conference, or online---can survive without editors (aka moderators); they would quickly devolve into unintelligible messes, and all the good writers would leave.

The vast majority of contributors here, including Moderators, are unpaid, unsupervised, and acting independently. Sometimes an editor will make the wrong decision; that is not abuse. However, for you to call it abuse is abusive, and the only reason that I'm not even more annoyed by your Question is that perhaps you thought that this was an official customer-support channel rather than a public forum. If you show disrespect to acer again, I'll delete it.

Apply command CycleBasis to G. Select the members of the output containing v. From these, select the one with the fewest elements. That number of elements is your answer.

Assumptions made with an assuming clause are only active for the command to which the clause is attached. Thus, there is no assumption applying to eta for the is command in question.

Your use of interface(showassumed= 0) obscured this information, which likely would've otherwise been apparent to you. Sure, those tildes on the variables are ugly. BUT, you should first get your code to work, then remove ugliness. Obscuring information also makes it more difficult for other people, such as me, to debug your code.

In your Maple initialization file, include the line

print(kernelopts(pid));

Then the number will be at the top of every worksheet.

Note that g1 is itself an equation: Q = RootOf(...). So, if you say eval(..., [Q= g1, ...]), the substitution becomes Q= (Q= ...). In other words, you're substituting an entire equation for Q when you meant to substitute only the right side of that equation. The same problem happens with g2 and T. To correct it:

eval(..., [g1, g2, ...other equations...])

Here's a one-line Answer, although perhaps less understandable than the one from @mmcdara :

(mul@op~@applyop~)((3-nops)*(`+`@op), 1, ListTools:-Collect((`{}`@op)~(L)));
                             190080

Some explanations:  (`{}`@op)~ converts the list pairs to sets to make the order irrelevant. This also changes [2,2] to {2}, which affects the sums done by (`+`@op). The (3-nops)* contributes a coefficient to compensate for that: (3-nops)({1,4}) = 1, (3-nops)({2}) = 2. Then all numbers are multiplied by mul@op~; there's no need to first multiply them pairwise. The applyop~ is used so that the (3-nops)*(`+`@op) is only applied to the 1st operand of each pair returned by Collect.

Ordinarily, (`+`@op) could be replaced by add, but the internal extra-optional-arguments syntax used by applyop makes that not work.

A surprisingly quick and easy analysis of the code behind eval[recurse] and reading of the help page ?has shows that eval[recurse] cannot possibly work correctly when there are lists or sets on the left sides of the substitution equations, and that this bug would be easy to fix. That the list is empty and substitutent is NULL are irrelevant. The code can be read by

showstat(`simpl/eval`::ModuleApply);  #Note: :: not :-

Note the use of has in lines 7 and 15 and this paragraph from ?has (3rd paragraph of Description):

• If the item that you want has to search for is itself a list or set, you must enclose it in a list or set. Otherwise, has will search for items in the list or set as described above.

The bug can be fixed by these steps:

kernelopts(opaquemodules= false):
interface(verboseproc= 2):
lprint[2](eval(`simpl/eval`:-ModuleApply));

In a fresh execution block, type (but don't press Enter)

`simpl/eval`:-ModuleApply:= 

:

Copy and paste the output of the lprint into the blank line in the execution block.

In lines 7 and 15, change the second argument of has to

`if`(y::{'list','set'}, [y], y)

In line 10 put the `simpl/eval`:- module prefix on Terminates1 and Terminates2.

In line 14 wrap the right side of := with an extra eval (with no second argument).

Add this line immediately after line 14:

if expr=() then return fi;

Press Enter, because we're ready to test the procedure.

lprint(eval[recurse]([[[[[]]]]], [[]= 'NULL']));
NULL

Like this:

Split:= (L::list(string), d::string)->
local p:= StringTools:-Search(d,L);
    (index~(L, `..`~(1, p-~1)), (parse@index)~(L, `..`~(p+~length(d), -1)))
:    
Split(["k$1","y$23","f$2.5"], "$");
                 ["k", "y", "f"], [1, 23, 2.5]

Here is an elegant way:

evalindets(sol, suffixed(_), ()-> n);

Here's another way, not necessarily any better, though I think it'd be educational for you to understand how this works:

Prod:= proc(L::list(algebraic))
local T:= table('sparse'), x;
    for x in L do T[x]+= x od;
    mul(eval(T))
end proc
: 
Prod([1,2,1,6,6,2,1,1,1,4,5,2,4,5,6,7,1]);
                             362880

Declaring a table sparse initializes the entry for each index to 0 even if the indices aren't yet known at the time of the declaration.

All of the details needed for your computations can be obtained from the matrix returned by GraphTheory:-AllPairsDistance. This works for both weighted and unweighted graphs.

VSdist:= proc(G::Graph)
uses GT= GraphTheory;
local 
    d:= GT:-AllPairsDistance(G), n:= op([1,1], d), n2:= n*(n-1)/2, 
    (D,D__min):= (op@[max,min]@rhs~@op)(2, d), B, A:= GT:-AdjacencyMatrix(G)
;
    if D=infinity then error "graph is disconnected" fi;
    table([
        'B__1'= -(B:= -add(d)/2), 'B__2'= (B+= D*n2), 'B__3'= B+D__min*n2,
        'B__4'= map['reduce'= `+`](x-> `if`(x=0, 0, 1/x), (D-~d)*~A)/2
    ])
end proc
:        

Assuming that you're going to do the 10 neighborhood computations from your other Question on the same graphs as these 15, it's easier and more efficient to do them in a single procedure. The following procedure does all 25 in 25 lines of code (just a coincidence). This works equally well, and does exactly the same thing, whether or not the graph is weighted. The procedure does not use the GraphTheory package; instead, all necessary information is extracted from op(4, ...) of the graph.

This procedure is not intended for directed graphs or graphs with self loops.

restart:
VS25:= proc(G::Graph)
local
   `C+`, `C*`, Csqrt, Cmax, A1, A2, A3, u, N, e:= 0, 
    V:= op(4, G), C:= nops~(V), n:= numelems(C), CN, m:= add(C)/2, E:= rtable(1..m), 
    Eput:= (_,v)-> (E[++e]:= (u,v))[1], Efunc:= (F,f)-> seq['fold'= F[]](f(E[e]), e= 1..m),
    (Add,Mul):= op(curry~(Efunc, [[`+`, 0], [`*`, 1]]))
;
    for u,N in V do CN(u):= add(C[[u, N[]]]); select['fold'= (Eput, 0)](`<`, N, u) od;
    C:= (max(C)+1) -~ C; 
    ((r-> `if`(r::integer[8], r, evalf(r)))~@table)([
        'A__01'= (A1:= Add((u,v)-> (`C+`(u,v):= C[u]+C[v]))),
        'A__02'= (A2:= Add((u,v)-> (`C*`(u,v):= C[u]*C[v]))),
        'A__03'= (A3:= Add(`C+`^2)), 'A__04'= Add(`C*`^2),
        'A__05'= Add((`C+`-2)^(1/2)/(Csqrt:= `C*`^(1/2))), 'A__06'= 2*Add(Csqrt/`C+`),
        'A__07'= 2*m*(n-1) - A1, 'A__08'= 2*m^2 - A1/2 - A2, 'A__09' = A3 - 2*A2,
        'A__10'= Add(m/(m-n+2)/Csqrt),                       'A__11'= (A1:= Mul(`C+`)), 
        'A__12'= (A2:= Mul(`C*`)), 'A__13'= A1/A2, 'A__14'= A2/A1, 'A__15'= A1*A2,
        'N__01'= Add((u,v)-> (`C+`(u,v):= CN(u)+CN(v)))/2,
        'N__02'= Add((u,v)-> (`C*`(u,v):= CN(u)*CN(v)))/2,
        'N__03'= Add(`C+`^2)/4, 'N__04'= Add((u,v)-> 1/(Cmax(u,v):= max(CN(u), CN(v)))),
        'N__05'= Add(`C*`/`C+`), 'N__06'= Add(2/`C+`), 'N__07'= Add(2/`C*`), 
        'N__08'= Add(4/`C*`^2), 'N__09'= Add(Cmax), 'N__10'= Add(`C+`/`C*`)
    ])
end proc
:
G:= GraphTheory:-SpecialGraphs:-HypercubeGraph(7);

G := Graph 1: an undirected unweighted graph with 128 vertices and 448 edge(s)

A:= CodeTools:-Usage(VS25(G)):
memory used=1.71MiB, alloc change=0 bytes, cpu time=16.00ms,
real time=21.00ms, gc time=0ns

interface(rtablesize= 25):
<sort([entries](A, pairs), key= lhs)>;

The output is a table, which is more robust than a Vector to the inevitable changes that you'll make. It can be converted to a Vector by the method shown in the last line of code.