[MathJax off]

E The Core Packages and the Idea behind their Splitting

I will try to explain the idea behind splitting the 6 core packages:

1. homalg

2. Modules

3. HomalgToCAS

4. IO_ForHomalg

5. RingsForHomalg

6. ExamplesForHomalg

E.1 The 6=2+4 split

The following is an attempt to explain the 6=2+4 split.

E.1-1 Logically independent

The package homalg is logically independent from all other packages in the project. And among the six core packages it is together with Modules the only package that has to do with mathematics. The remaining four packages are of technical nature. More precisely, homalg is a stand alone package, that offers abstract homological constructions for computable Abelian categories. But since the ring of integers (at least up till now) is the only ring which for the purposes of homological algebra is sufficiently supported in GAP (--> Modules: Rings supported in a sufficient way), Modules can put the above mentioned abstract constructions into action only for the ring of integers and by generic (but of course non-efficient) methods for any of its residue class rings (Simon Görtzen's package Gauss adds the missing sufficient support for \(ℤ/p^n\) and \(ℚ\) to GAP and his other package GaussForHomalg makes this support visible to Modules).

E.1-2 Black boxes

The package Modules uses rings and matrices over these rings as a black box, enabling other packages to "abuse" homalg to compute over rings other than the ring of integers by simply providing the appropriate black boxes. And whether these rings and matrices are inside or outside GAP is not at all the concern of homalg. Even the GAP representation for external rings, external ring elements, and external matrices are declared in the package HomalgToCAS and not in homalg.

E.1-3 Summing up

One of the main concepts of the homalg project is that high level and low level computations in homological algebra can and should be separated. So splitting homalg from the remaining 4 core packages is just emphasizing this concept. Moreover, homalg is up till now by far the biggest package in the project and will probably keep growing by supporting more basic homological constructions, whereas the other 4 packages will remain stable over longer time intervals.

E.2 The 4=1+1+1+1 split

The following is meant to justify the remaining 4=1+1+1+1 split.

E.2-1 HomalgToCAS

The package HomalgToCAS (which needs the homalg package) includes all what is needed to let the black boxes used by homalg reside in external computer algebra systems. So as mentioned above, HomalgToCAS is the right place to declare the three GAP representations external rings, external ring elements, and external matrices. Still, HomalgToCAS is independent from the external computer algebra system with which GAP will communicate and independent of how this communication physically looks like.

E.2-2 IO_ForHomalg and Alternatives

The package IO_ForHomalg (which needs HomalgToCAS) allows GAP to communicate via I/O-streams with computer algebra systems that come with a terminal interface. IO_ForHomalg uses Max Neunhöffer's IO package, yet it is independent from the specific computer algebra system, as long as the latter provides a terminal interface. Splitting IO_ForHomalg from HomalgToCAS gives the freedom to replace the former by another package that lets GAP communicate with an external system using a different technology. So making IO_ForHomalg a package of its own makes it clear for developers of a new communication method which package of the homalg project has to be imitated/replaced. To be concrete, Thomas Bächler wrote a package called MapleForHomalg that enables GAP to communicate with Maple without the need for a terminal interface.

E.2-3 RingsForHomalg

The package RingsForHomalg (which needs HomalgToCAS) provides the details of the black boxes homalg relies on. The details of the black boxes of course depend on the external computer algebra system (Singular, MAGMA, Macaulay2, Maple, Sage, ...), but are independent from the way the communication takes place. So it can be used either with IO_ForHomalg, with MapleForHomalg, or with any future communication package.

E.2-4 Your own RingsForHomalg

If someone needs to support a ring in some computer algebra system that GAP can already communicate with, but where the ring is not supported by RingsForHomalg yet, she or he needs to imitate/replace RingsForHomalg (as Simon Görtzen did with his GaussForHomalg, where the computer algebra system was GAP itself, extended by his package Gauss). Any substitute for RingsForHomalg -- as it only needs HomalgToCAS -- will again be independent from the way how GAP communicates with the computer algebra system that hosts the ring. This should encourage people to link more external systems to homalg without being forced to join the development of the package RingsForHomalg. They can simply write their own package and get the full credit for it.

E.2-5 ExamplesForHomalg

The package ExamplesForHomalg (which needs RingsForHomalg) contains example scripts over various rings that are written in a universal way, i.e. independent from the system that hosts the rings. These examples cannot be part of the homalg package as they are defined over rings that GAP does not support. The package ExamplesForHomalg is meant to be the package where anyone can contribute interesting examples using homalg without necessarily contributing to the code of any of the remaining core packages.

E.2-6 Documentation

Splitting the core packages is part of documenting the project. The complete manuals of the homalg and ExamplesForHomalg packages (maybe apart from the appendices) can then be free from any non-mathematical technicalities the average user is not interested in. A documentation of the three packages HomalgToCAS, IO_ForHomalg, and RingsForHomalg will be rather technical and of interest mainly for developers.

E.2-7 Crediting

Everyone is encouraged to contribute to the homalg project. The project follows the philosophy of avoiding huge monolithic packages and splitting unrelated tasks. This should enable contributers to write their own packages (building on other existing packages) and getting the full credit for their work, which can then be easily distinguished from the work of others.

E.2-8 Stability

A huge monolithic package can never stabilize, even though parts of it will stay frozen for a long period of time. The splitting makes it likely that parts of the project together with their documentation quickly reach a stable state.

generated by GAPDoc2HTML