The Maple package homalg is now part of the homalg project
developed in GAP4. As part of the new project it provides a unified
interface for the GAP4 implementation of homalg to access the
different Maple ring packages.
Why Maple?
Choosing Maple for implementing homalg was dictated by the
pre-existence of several ring packages developed in our workgroup written in
Maple, that were (and to some extent are still) not available in other
free computer algebra systems. The main reason for choosing Maple to
develop these ring packages was that Maple allows one to work relatively
easy with differential algebras over differential fields. The Maple
package Janet provides the Janet division algorithm for these rings.
Why not Maple?
Maple is commercial, even for the purely scientific academic use.
In fact homalg doesn't rely on anything specific in Maple which is not
available in an open system such as GAP4 for
example. On the contrary, we believe that a system like
GAP4 provides with its structures, method selection
schemes and lazy evaluation a way to reduce the data overhead and hence the
overall performance of homalg drastically.
Beside choosing a computer algebra system with method selection capabilities, we
want to make future implementations more flexible. For example, we want to
still be able to use our differential ring packages written in Maple, without
being forced to rewrite them elsewhere, simply because they are still best
placed in Maple. We also want to use the Singular
engine to compute Gröbner basis, which is now available for the wide
class of G-algebras implemented in Plural. In short, we want to interact with as
much systems as possible. To remedy the drawback of moving huge data from one
system to the other, the computed data will be kept on the computing system
side and homalg will solely receive a "pointer" to the result. This will
minimize the data transfer to an extreme and should even, to some extent,
enable us to parallelize the computations.
In general, intermediate results tend to be much larger than end
results. Besides, lots of computations in homological algebra need a fair
amount of intermediate steps. Hence restricting the data transfer to the end
result would be an enormous gain. And often enough one is even only interested
in a true/false answer, saying for example if a module vanishes or if a
sequence is exact or not, making real data transfer completely obsolete.
This will also mean that the operations in homalg that directly get in
touch with data, such as taking the union of two lists of relations or
transposing a matrix, must then be transfered to the package where the
computations reside. This must be done for each such package. This is an
unavoidable, but more or less the only drawback of this philosophy.
For the current features of homalg, please
see the Introduction.
Todo
After putting everything in GAP4 we plan the following:
- applications: topology, cohomology of groups, number theory, control theory ...
- spectral sequences
- create and link more ring packages to homalg
- handle all functors on an equal footing, regardless of the (source
and) target abelian category