The original implementation of homalg in Maple by Daniel Robertz and myself hit several walls. The speed of the Gröbner basis routines in Maple was the smallest issue. The rising complexity of data structures for high level algorithms (bicomplexes, functors, spectral sequences, ...) became the main problem. We very much felt the need for an object-oriented programming language, a language that allows defining complicated mathematical objects carrying properties and attributes and even containing other objects as subobjects.
As we were pushed to look for an alternative to Maple, our wish list grew even further. Section B.2 is a summary of this wish list.
In 1993 J. Neubüser addressed the necessity of free software in mathematics:
"You can read Sylow's Theorem and its proof in Huppert's book in the library without even buying the book and then you can use Sylow's Theorem for the rest of your life free of charge, but - and for understandable reasons of getting funds for the maintenance, the necessity of which I have pointed out [...] - for many computer algebra systems license fees have to be paid regularly for the total time of their use. In order to protect what you pay for, you do not get the source, but only an executable, i.e. a black box. You can press buttons and you get answers in the same way as you get the bright pictures from your television set but you cannot control how they were made in either case. With this situation two of the most basic rules of conduct in mathematics are violated. In mathematics information is passed on free of charge and everything is laid open for checking. Not applying these rules to computer algebra systems that are made for mathematical research [...] means moving in a most undesirable direction. Most important: Can we expect somebody to believe a result of a program that he is not allowed to see? [...] And even: If O'Nan and Scott would have to pay a license fee for using an implementation of their ideas about primitive groups, should not they in turn be entitled to charge a license fee for using their ideas in the implementation?"
I had the pleasure of being one of his students.
The detailed copyright for GAP can found on the GAP homepage under Start > Download > Copyright.
Not only does GAP have the potential of natively supporting a wide range of mathematical structures, but finite groups and their representation theory are already an area of expertise. So there are at least some areas where one does not need to start from scratch.
But one could argue that rings are more central for homological algebra than finite groups, and that GAP4, as for the time when the homalg project was shaping, does not seriously support important rings in a manner that enables homological computations. This drawback would favor, for example, Singular (with its subsystem Plural) over GAP4. Point B.2-3 indicates how this drawback was overcome in a way, that even gave the lead back to GAP4.
One of my future plans for the homalg project is to address moduli problems in algebraic geometry (favorably via orbifold stacks), where discrete groups (and especially finite groups) play a central role. As of the time of writing these lines, discrete groups, finite groups, and orbifolds are already in the focus of part of the project: The package SCO by Simon Görtzen to compute the cohomology of orbifolds is part of the currently available homalg project.
For the remaining points the choice of GAP4 as the programming language for developing homalg was unavoidable.
With the excellent IO package of Max Neunhöffer GAP4 is able to communicate in an extremely efficient way with the outer world via bidirectional streams. This allows homalg to delegate things that cannot be done in GAP to an external system such as Singular, Sage, Macaulay2, MAGMA, or Maple.
The object-oriented programming philosophy of GAP4 was developed by mathematicians who wanted to handle complex mathematical objects carrying properties and attributes, as often encountered in algebra and geometry. GAP4 was thus designed to address the needs of mathematical object-oriented programming more than any other language designed by computer scientists. This was primarily achieved by the advanced method selection techniques that very much resemble the mathematical way of thinking.
Unlike the common object-oriented programming languages, methods in GAP4 are not bound to objects but to operations. In particular, one can also install methods that depend on two or more arguments. The index of a subgroup is an easy example of an operation illustrating this. While it would be sufficient to bind a method for computing the order of a group to the object representing the group, it is not clear what to do with the index, since its definition involves two objects: a group G and a subgroup U. Note that the index of U in a subgroup of G containing U might also be of interest. Things become even more complicated when the arguments of the operation are unrelated objects. Moreover, binding methods to operations makes it possible for the programming language to support the installation of one or more methods for the same operation, depending on already known properties or attributes of the involved objects.
Moreover GAP4 supports so-called immediate and true methods. This considerably simplifies teaching theorems to the computer. For example it takes one line of code to teach GAP4 that a reflexive left module over a ring with left global dimension less or equal to two is projective. These logical implications are installed globally and GAP4 immediately uses them as soon as the respective assumptions are fulfilled. This mechanism enables GAP4 to draw arbitrary long lines of conclusions. The more one knows about the objects involved in the computation the more specialized efficient algorithms can be utilized, while other computations can be completely avoided. homalg is equipped with plenty of logical implications for rings, matrices, modules, morphisms, and complexes.
When all these features become relevant to what you want to do, there is hardly an alternative to GAP4.
Being able to install several methods for a single operation (--> B.2-4) has the additional advantage of making GAP4 packages easily extendible. If you have an algorithm that, in a special case, performs better than existing algorithms you can install it as a method which gets triggered when the special case occurs. You don't need to break existing code to insert an additional elif section contributing to an increasing unreadability of the code. Even better, you don't even need to know anything about the code of other existing methods. In addition to that, you can add (maybe missing) properties and attributes (along with methods to compute them) to existing objects.
Although the python-based Sage fulfills most of the above requirements, it was primarily the points expressed in B.2-4 that finally favored GAP4 over Sage: The object-orientedness of python, although very modern, does not cover the needs of the homalg package. At this place I would like to thank William Stein for the helpful discussion about Sage during the early stage of developing homalg, and to Max Neunhöffer who explained me the advantages of the object-oriented programming in GAP4.
In what follows homalg often refers to the whole homalg project.
First of all, Sage is a huge project, that, among other things, is intended to replace commercial, general purpose computer algebra systems like Maple and Mathematica. So while Sage targets (a growing number of) different fields of computer algebra, homalg only focuses on homological, and hopefully in the near future also homotopical techniques (applicable to some of these different fields). The two projects simply follow different goals and are different in scale.
Sage is based on python and the C-extension cython while homalg is based on GAP4. Quoting from an email response William Stein sent me on the 25. of February, 2008: "Sage *is* Python + a library". Although I seriously considered developing homalg as part of Sage, for the reason mentioned in B.2-4 I finally decided to use GAP4 as the programming language.
Both Sage and homalg rely for many things on external computer algebra systems. But although one can simply invoke a GAP shell or a Singular shell from within Sage, Sage normally runs the external computer algebra systems in the background and tries to understand the internals of the objects residing in them. An object in the external computer algebra system is wrapped by an object in Sage and supporting this external object involves understanding its details in the external system. homalg follows a different strategy: The only external objects homalg needs (beside rings) are non-empty matrices. And being zero or not is basically the only thing homalg wants to know about a matrix after knowing its dimension. I myself was stunned by this insight, which culminated in Modules: The principle of least communication (technical).
In particular, Sage can make use of all of homalg, but for in order to make full use, Sage needs to understand the internals of the homalg objects. On the contrary, homalg can only make limited use of Sage (or of virtually any computer algebra system that supports rings in a sufficient way (--> Modules: Rings supported in a sufficient way)), but without the need to delve into the inner life of the Sage objects.
generated by GAPDoc2HTML