It provides procedures to construct basic objects in homological algebra:
modules (generators, relations)
submodules (as images of maps)
maps
Beside these so-called constructors Modules provides operations to perform computations with these objects. The list of operations includes:
resolution of modules
images of maps
the functors Hom and TensorProduct (Ext and Tor are then provided by homalg)
test if a module is torsion-free, reflexive, projective, stably free, free, pure
determine the rank, grade, projective dimension, degree of torsion-freeness, and codegree of purity of a module
Using the philosophy of GAP4, one or more methods are installed for each operation, depending on properties and attributes of these objects. These properties and attributes can themselves be computed by methods installed for this purpose.
Through out this manual the following terminology is used. We say that a computer algebra system sufficiently supports
a ring R, if it contains procedures to effectively solve one-sided inhomogeneous linear systems XA=B and AX=B with coefficients over R (--> Principal limitation).
Note that the solution space of the one-sided finite dimensional system YA=0 (resp. AY=0) over a left (resp. right) noetherian ring R is a finitely generated left (resp. right) R-module, even if R is not commutative. The solution space of the linear system X_1 A_1 + A_2 X_2 + A_3 X_3 A_4=0 is in general not an R-module, and worse, in general not finitely generated over the center of R. Modules can only handle homological problems that lead to one sided finite dimensional homogeneous or inhomogeneous systems over the underlying ring R. Such problems are called problems of finite type over R. Typically, the computation of Hom(M,N) of two (even) finitely generated modules over a noncommutative ring R is generally not of finite type over R, unless at least one of the two modules is an R-bimodule. Also note that over a commutative ring any linear system can be easily brought to a one-sided form. For more details see [BR08].
Modules uses the so-called homalgTable, which is stored in the ring, to know how to delegate the necessary matrix operations. I.e. the homalgTable serves as a small dictionary that enables Modules to speak (as much as needed of) the language of the computer algebra system which hosts the ring and the matrices. The GAP internal ring of integers is the only ring which Modules endows with a homalgTable. Other packages like GaussForHomalg and RingsForHomalg provide dictionaries for further rings. While GaussForHomalg defines internal rings and matrices, the package RingsForHomalg enables defining external rings and matrices in a wide range of (external) computer algebra systems (Singular, Sage, Macaulay2, MAGMA, Maple) by providing appropriate dictionaries.
Since these dictionaries are all what is needed to handle matrix operations, Modules does not distinguish between handling internal and handling external matrices. Even the physical communication with the external systems is not at all a concern of Modules. This is the job of the package IO_ForHomalg, which is based on the powerful IO package of Max Neunhöffer. Furthermore, for all structures beyond matrices (from relations, generators, and modules, to functors and spectral sequences) Modules no longer distinguishes between internal and external.
Linking different systems to achieve one task is a highly attractive idea, especially if it helps to avoid reinventing wheels over and over again. This was essential for homalg, since Singular and MAGMA provide the fastest and most advanced Gröbner basis algorithms, while GAP4 is by far the most convenient programming language to realize complex mathematical structures (--> Appendix homalg: Why GAP4?). Second, the implementation of the homological constructions is automatically universal, since it is independent of where the matrices reside and how the several matrix operations are realized. In particular, homalg will always be able to use the system with the fastest Gröbner basis implementation. In this respect is homalg and all packages that build upon it future proof.
No, on the contrary. There are a lot of specialized algorithms installed in homalg. These algorithms are based on properties and attributes that -- thanks to GAP4 -- homalg objects can carry (--> Appendix homalg: GAP4 is a mathematical object-oriented programming language): Not only can homalg take the special nature of the underlying ring into account, it also deals with modules, complexes, ... depending on their special properties. Still, these special algorithms, like all algorithms in homalg, are independent of the computer algebra system which hosts the matrices and which will perform the several matrix operations.
Linking different systems can also be highly problematic. The following two points are often among the major sources of difficulties:
Different systems use different languages:
It takes a huge amount of time and effort to teach systems the dialects of each others. These dialects are also rarely fixed forever, and might very well be subject to slight modifications. So the larger the dictionary, the more difficult is its maintenance.
Data has to be transferred from one system to another:
Even if there is a unified data format, transferring data between systems can lead to performance losses, especially when a big amount of data has to be transferred.
Solving these two difficulties is an important part of Modules's design. Modules splits homological computations into two parts. The matrices reside in a system which provides fast matrix operations (addition, multiplication, bases and normal form computations), while the higher structures (modules, maps, complexes, chain morphisms, spectral sequences, functors, ...) with their properties, attributes, and algorithms live in GAP4, as the system where one can easily create such complex structures and handle all their logical dependencies. With this split there is no need to transfer each sort of data outside of its system. The remaining communication between GAP4 and the system hosting the matrices gets along with a tiny dictionary. Moreover, GAP4, as it manages and delegates all computations, also manages the whole data flow, while the other system does not even recognize that it is part of a bidirectional communication.
The existence of such a clear cut is certainly to some extent due to the special nature of homological computations.
Q: Does outsourcing the matrices mean that Modules is able to compute spectral sequences, for example, without ever seeing the matrices involved in the computation?
A: Yes.
Q: Can Modules profit from the implementation of homological constructions like Hom, Ext, ... in Singular?
A: No. This is for a lot of reasons incompatible with the idea and design of Modules.
Q: Are the external systems involved in the higher algorithms?
A: No. They host all the matrices and do all matrix operations delegated to them without knowing what for. The meaning of the matrices and their logical interrelation is only known to GAP4.
Q: Do developers of packages building upon Modules need to know anything about the communication with the external systems?
A: No, unless they want to use more features of the external systems than those reflected by Modules. For this purpose, developers can use the unified communication interface provideb by HomalgToCAS. This is the interface used by Modules.
Chapter 2 describes the installation of this package, while Chapter 3 provides a short quick guide to build your first own example, using the package ExamplesForHomalg. The remaining chapters are each devoted to one of the homalg objects (--> 1.1-1) with its constructors, properties, attributes, and operations.
generated by GAPDoc2HTML