The problem here is that loops (self-incident vertices) are not supposed to be allowed, but the Digraph command fails to detect this.  (The diagonal entries of an incidence matrix should all be equal to 0.)  The IsIsomorphic command (and many other GraphTheory package commands) will not work correctly with graphs that have loops.  There is an explicit check for this when the Digraph command is presented with a set of arcs:

> with( GraphTheory ):
> Digraph( [ 1, 2, 3 ], { [1,2], [2,2], [2,3] } );
Error, (in GraphTheory:-Graph) invalid edge/arc: [2, 2]
 

However, a similar check should be (but is not, presently) implemented for other forms of input, such as adjacency matrices.  A bug report for this has been created.

The difficulty with computing in some of the large sporadic simple groups, like the Baby Monster, is not that the group is so large, but that it has no small degree representation.  That is why this group is represented symbolically in Maple.  For example, Maple can compute quite readily with the (simple) alternating group of degree 32, which is larger than the Baby Monster.  There is a matrix representation for the Baby Monster of dimension 4370 over the field of order two (see  this Atlas entry). However, Maple does not yet implement linear groups.  In the past, specialised distributed disk-based techniques have been used to compute with permutation representations for the large sporadic simple groups.  See, for example, the following paper: Eric Robinson and Gene Cooperman, "A Parallel Architecture for DiskBased Computing over the Baby Monster and Other Large Finite Simple Groups",  Proceedings of the 2006 international symposium on Symbolic and algebraic computation, Pages 298-305.

James McCarron, Mathematics, Maplesoft

For most problems involving finitely generated abelian groups, using the LinearAlgebra package, as indicated by Axel Vogt, seems to be the best approach at present.

Knowing, as we do, that your groups is free abelian of rank three, you can create an isomorphic copy using the GroupTheory package in a couple of ways.

with( GroupTheory ):

First, you can form the direct product of three infinite cyclic groups.

DirectProduct( CyclicGroup( infinity ), CyclicGroup( infinity ), CyclicGroup( infinity ) );

Second, you can enter a presentation directly.

< x, y, z | x.y = y.x, x.z = z.x, y.z = z.y >;

However, neither of these allow you to study the group as a finitely generated abelian group, as such.  I expect you would most likely prefer to think of your group as a subgroup of a free abelian group of rank 4, as written.  Most questions about such groups amount to doing linear algebra over the integers.

What would be nice is an interface to those linear algebra algorithms, already present in the LinearAlgebra package, through some kind of group-theoretic interface within the GroupTheory package itself.  And, indeed, supplying such an interface is something that was considered.  However, we would get all of that "for free", as it were, within a more general context of polycyclic groups, a broader class of groups for which there are efficient algorithms to solve many of the same basic questions.  Implementing polycyclic groups is a much bigger project, though it is something that I hope we may eventually find time to do.  Of course, it is entirely possible that this design decision might one day be revisited.  As always, user feedback strongly influences our decisions about what to work on, so we are grateful for your suggestions.

If you look at the output of your call to the Vector constructor, you'll see that the components of the vector that is produced refer to the symbol v, rather than x.   So, you should change the second argument in your call to makeproc as follows:

test_file := makeproc( out, v :: array( 1 .. 2 ) );

One has to admit that this is a bit confusing since, using vector (lower case "v") allows you to use the same symbol to refer to the entire vector and its components, which is not possible with Vector (upper case "V").  This is because the older vector has last name evaluation rules (see ?last_name_eval in the help system), while the newer Vector objects do not.

Hope this helps,

James McCarron, Maplesoft

You might find the process:-launch command helpful.  See the help page  ?process(deprecated)/launch  for more information.

James McCarron, Maplesoft

I'll elaborate a little on good advice already given.  If you remove the ::evaln modifier in your definition of the procedure func_encaps it seems to work just fine.

By adding ::evaln to the parameter specification in your definition of func_encaps you have caused that procedure to pass the name H to the unapply call within it.  This in turn produces a procedure (essentially) equivalent to

proc( y::float, a::float, b::float ) global H; return H end;

which is almost certainly not what you intended.  This procedure can be compiled but, since the global name H does not evaluate to a numeric value at runtime, you get the error you see.

It is almost always a bad idea to add ::evaln (or, likewise, ::uneval) to a procedure argument specification.  These modifiers force the procedure to use special evaluation rules, whcih are meant to be used only in unusual circumstances.

Hope this helps.

James McCarron, Maplesoft

The error indicates that an invalid pattern dictionary (see ?StringTools/PatternDictionary ) was detected during either shutdown or garbage collection.  Without more information, it is impossible to surmise how this might have happened.  However, if it occurs during shutdown (or, equivalently, a restart), you can safely ignore it.

In general, there is no method that I know of that will allow you to get the name of the module to which an arbitrary module export belongs.  However, there is a method that works for named modules.   Normally, a module does not have a (sort of) canonical name, other than any names to which it may be assigned.  However, by using an alternate module definition syntax, you can create a named module, which does have a "canonical" name.   In this case, the canonical name is stored in the attributes of each of its exports.

For example, creating a module in the usual way, we see that there are no attributes on the export a.

> m := module() export a; end:
> attributes( m:-a );

However, by creating a named module, we get the following:

> module m1() export a; end:
> attributes( m1:-a );
                                modulename = m1

Note the different syntax.  There is no assignment statement used in the creation of m1.  We simply evaluate the module definition with the name m1 after the keyword module as shown, and the assignment takes place behind the scenes, as it were.  (Note also that the name m1 is now protected.)

Notice that the export m1:-a has the attribute modulename = m1.   Using this information, we can write a simple routine to pick up the name of a named module.

> GetModuleName := proc( e )
       local a, pos;
       a := [attributes]( e );
       `if`( membertype( 'identical'( 'modulename' ) = 'name', a, 'pos' ), 
                a[ pos ], NULL )
 end proc:
> GetModuleName( m:-a );
> GetModuleName( m1:-a );
                                m1

I should point out that there is another important, and much more common way in which a module may acquire a name.  Whenever a module is saved to a repository (.mla file), it is given a name, that being the one under which it was saved.  In this way, all the modules that are shipped with Maple as part of the standard library are, in fact, named modules.

> GetModuleName( LinearAlgebra:-Determinant );
                                 LinearAlgebra

Here, the export Determinant of the LinearAlgebra package has stored among its attributes the equation modulename = LinearAlgebra because LinearAlgebra is a named module by virtue of having been saved to a repository.

In general, named modules should be used with some care.  For example, suppose that you assigned the named module m1 above to the name u, and then saved it in a repository using the name u, via a call such as savelib(u);.  It would be saved just fine, and you could refer to it in other Maple sessions using the name u.  However, the procedure GetModuleName defined above would return the original name m1 given to it when it was created.  This is because it is the original name m1 that is stored in the attributes of the exports.

> attributes( u:-a );
                                modulename = m1

There is, therefore, much potential for confusion with named modules.