@vv

I really didn't want to go there. Your "workaround" amounts to flipping the arguments to the IsIsomorphic() command

If I strip out all the extraneous crap from your workaround then I am left with

IsIso := proc(G1, G2)
                       try         GraphTheory:-IsIsomorphic(G1,G2);
                       catch:   GraphTheory:-IsIsomorphic(G2,G1);
                       end try;
           end proc:

Note the argument order swap in the IsIsomorphic() command. So extending my previous example, it is equivalent to

with(GraphTheory):
G1:=Digraph(Matrix(3, 3, [[0, 0, 0], [0, 0, 1], [0, 1, 0]])):
G2:=Digraph(Matrix(3, 3, [[1, 0, 0], [0, 1, 0], [0, 0, 0]])):
IsIsomorphic(G1,G2);
IsIsomorphic(G2,G1)

where the first IsIsomorphic() command errors, and the second returns 'false'. I hope we can agree that for a command such as IsIsomorphic(), argument order ought to be completely irrelevant???

In my view this is not an acceptable workaround, because

1. You have not identified the original cause of the error, so you cannot guarantee that this "workaround" always works
2. I mean you have tried this "wprkaround" with all possible graphs, of all vertex counts and edge configurations - haven't you? Cos if you haven't, it isn't a "workaround"
3. The IsIsomorphic() command is broken (and it has nothing to do with 'loops'), but you haven't proved that you can fix it, except for one specific set of graphs

In the OP's original problem there are 512 adjacency matrices, producing 512 digraphs. Including the case where one checks whether a graph is isomorphic to itself, this means that there 131328 isomorphism checks. Of these 131328 checks, my original code returns

Is isomorphic           1648
Is not isomorphic 129677
Errors                            3
                            ----------
Sum                     131328

Now if I consider the first pair of graphs which cause an error - indexed as 11 and 273 in my original, the following statements are true

1. Graph index 11 is tested for isomorphism against 512 other graphs (including itself), producing either true or false 511 times, and erroring once
2. Graph index 273 is tested for isomorphism against 512 other graphs (including itself), producing either true or false 511 times, and erroring once
3. When graph index 11 is tested for isomorphism against graph index 273, it always errors
4. Both graph index 11 and graph index 273 contain a loop - but 511 times out of 512 this causes no problem at all

Conclusion: the error is not caused by "loops" - but there is something special about the combination of graph index 11 and graph index 273 - and I have absolutely no idea what it is!

Reading this thread just convinces me that no-one else has a clue either

@dharr  @vv 

Run this

with(GraphTheory):
G1:=Digraph(Matrix(3, 3, [[0, 0, 0], [0, 0, 1], [0, 1, 0]])):
G2:=Digraph(Matrix(3, 3, [[1, 0, 0], [0, 1, 0], [0, 0, 0]])):
IsIsomorphic(G1,G2);

Now what, exactly, is the "workaround" you are talking about?

@dharr 

Consider the case where one selects only those graphs whose adjacency matrix has trace=3: in other words, three loops, plus (possibly) other edges. There are 64 of these.

The attached selects only these 'loopy' graphs and then checks for isomorphism. It runs with no errors!!

weird2.mw

I have also added an execution group to my original worksheet to retrieve the adjacency matrices of the failing pairs. I don't see any particular "pattern" in these matrix pairs - but I'm prepared to accept that there must be one!

weird.mw

I agree with dharr that running my original code in Maple 2015.2 produces 25 error events, rather than the 3 error events which occur in Maple 2016.2. I have no idea why this discrepancy should occur.

I have to disagree with james1482 that the problem is associated with 'loops' in the graphs. A 'loop' will occur any time a diagonal element in the adjacency matrix is '1' rather than '0'. So if this assertion were true, successful evaluation would only occur if all diagonal elements were '0'.  Only 64 out of the 512 possible adjacency matrices will have zero diagonal - if this assertion were true, ther would be way more than three failures (in Maple 2016.2) - or even 25 (in Maple 2015.2)

I find Carl Love analysis interesting (mainly becuase no errors occur!!). It is obviously true that when one is checking isomorphisms across a finite set of data, then the afore-mentioned data can be split into equivalence classes. However, this seems to  "sidestep"  the problem. If I "reduce" my original response to something even simpler, with the code

    restart:
    with(combinat):
    with(GraphTheory):
#
# Generate a list of graphs from 3*3 adjacency
# matrices whose entries are all combinations
# of 0,1 - so there should be 2^9=512 graphs
#
    n:=3:
    matList:= [ seq( Matrix(n,n,j) ,
                                j in permute([0$(n*n), 1$(n*n)],n*n)
                             )
                    ]:
#
# Check a few Isomorphisms
#
   IsIsomorphic( Digraph(matList[10]), Digraph(matList[272]));
   IsIsomorphic( Digraph(matList[10]), Digraph(matList[273]));
   IsIsomorphic( Digraph(matList[10]), Digraph(matList[274]));
   IsIsomorphic( Digraph(matList[11]), Digraph(matList[272]));
   IsIsomorphic( Digraph(matList[11]), Digraph(matList[273])); # Why does this ERROR
   IsIsomorphic( Digraph(matList[11]), Digraph(matList[274]));
   IsIsomorphic( Digraph(matList[12]), Digraph(matList[272]));
   IsIsomorphic( Digraph(matList[12]), Digraph(matList[273]));
   IsIsomorphic( Digraph(matList[12]), Digraph(matList[274]));

Then why do 8 out the above 9 isomorphism checks 'run' (and produce false), while one 'ERRORS' ??

What is 'special' about IsIsomorphic( Digraph(matList[11]), Digraph(matList[273])) ??

If you want anyone to help, you need to load executable code - no-one is going to retype code from a "picture"

Use the big green up-arrow in the Mapleprimes toolbar to upload both your worksheet (.mw file) and your data (.txt file)

Well, based on my original suggestion, ie

You are loading the Physics package, which extends the functionality of 'dot' operator '.', but you don't need this extended functionality  so I would comment this out

and your (two) subsequent responses, it would seem that your error is caused by the "extended functionality" of the "." operator whenever the Physics package is loaded. I can only think of two workarounds for this problem

1. I cannot replicate your error (with or without the Physics package) using Maple 18.02. So maybe something got fixed between your version (18.01) and mine. Assuming that you have an appropriate license for Maple 18.01, then you ought to be able to download/install Maple 18.02 - in which case your problem should disappear
2. If you cannot download/install Maple 18.02 for some reason (and I can't see why!) then I suggest that you do not ovelrload the complete Physics package, but instead access any command in that package using the "long form" - eg Physics:-CommandName, as and when required
3. If you are doing "fairly simple" Lagrangian Mechanics, the you *might* be able to bypass the Physics package completely, by using commands from the VariationalCalculus() package

Some random thoughts

1. You can check the precise Maple build, just by typing version() at the Maple prompt
2. You are loading the Physics package, which extends the functionality of 'dot' operator '.', but you don't need this extended functionality  so I would comment this out
3. Use the variables "palette" to check that all of the variables have the types/dimensions which you expect.
4. Double-check (3) above by inserting the commands op([0..2], variableName), where variableName is omegab, Rb, JOL1, qdot
5. I notice that you are using 2D math input in document mode. My preference is to use 1D input in worksheet mode, because the latter *seems* to generate fewer 'strange' parsing errors. I have (crudely) converted your original to use 1-D input in worksheet mode (see the attached). On my machine this gives the same answer as your original. Does it work on your machine?

wksmode.mw

On 64-bit Windows 7

1. Using 64-bit Maple 18.02, build version: User Interface: 991181; Kernel: 991181; Library: 991181, code executes with no errors.
2. Using 64-bit Maple 2015.2, build version: User Interface: 1097895; Kernel: 1097895; Library: 1097895; code executes with no errors.
3. Using 64-bit Maple 2016.2, build version; User Interface: 1194701; Kernel: 1194701; Library: 1194701; code executes with no errors

So precisely which OS and which Maple version are causing the problem?????

Use the big green up-arrow in the Mapleprimes toolbar to upload your worksheet

Because when I make this change, your code executes (slowly!) with no error messages.

Now I can see all sorts of things in this code which *look* like logical errors, but with the change of [i.j] to [i,j], I no longer get any error message such as

"Error, Array index out of range"

Since I have to assume that you are still getting some kind of error message, please specify what it is, because this has to be addressed before we can make a start on what I think(?) might be logical errors

but the following *seems* to work

restart;with(LinearAlgebra):
B:=RandomVector(20)*~f:
A:=Vector([U[0, 0], U[0, 1], U[1, 0], U[1, 1], V[0, 0], V[0, 1], V[1, 0], V[1, 1], W[0, 0], W[0, 1], W[1, 0], W[1, 1], Phi[0, 0], Phi[0, 1], Phi[1, 0], Phi[1, 1], Xi[0, 0],Xi[0, 1], Xi[1, 0], Xi[1, 1]]):
varList:={seq( StringTools:-Split(convert(j,string),"[")[1], j in A)}:
for f to 11 do
    assign~(A=~B):
#
# random check on variable assignment
#
    printf("%6d%6d\n", U[0,0], Xi[0,1]);
    seq( unassign( convert(j,name)), j in varList);
 end do:

First of all I want to stress that I concur with acer, Carl Love, vv (and maybe others). I cannot envisage any problem where assigning 10⁶ variables then immediately unassigning them is a good idea. In fact I would describe it as madness.

Please, when you are in a hole - stop digging.

In case you think this is some excuse for my being unable to unassign an unspecified amount of variables with unknown names, then I attach the following, which works for the four-variable test case you supplied. (There are probably other, more efficient, ways to do this.)

unassign2.mw

Please don't use the above - rethink/restructure your fundamental problem

First time through the loop, supplied command will make the assignments

x:=1;
y:=2;
z:=3:
t:=4:

Consider what this means for the matrix A - it becomes [[1, 2], [3, 4]]. Now think what happens second time through the loop at the statement C:=A: C is assigned to [[1, 2], [3, 4]]. I hope you see the problem!

Easiest way to fix this is to unassign x, y, z, t as the final statements in the for loop. See the attached

unassign.mw

If you want/need to debug code, a "breakpoint" is a point in your code where you want execution to stop- ususually so that you can check something - like the values of any variables which have been computed up to that point are "sensible"

There are (at least) a couple of ways to insert such a 'breakpoint' - one is to insert the DEBUG() command at the appropriate point in your worksheet. The first example on the ?DEBUG help page should illustrate its use. One advantage of the DEBUG() command is that it can be inserted at the 'top-level' in your worksheet.

The second method of inserting a breakpoint is to use the stopat() command, which is generally more appropriate when you want to stop somewhere inside a procedure, since it accepts procedure names and line numbers as arguments. Notice that the relevant line number would be that which is returned by running showstat() with the procedure name as argument. Again the help for the stopat() command provides a simple, but workable example

There is a more extended example of debugger use in chapter 16 of the current Maple Programming Guide