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