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.    

 
 

Future Development of homalg
(already realized)

 

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.
 

Dreaming further
(already realized)

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: