1 Introduction

1.1 What is the role of the **Modules** package in the **homalg** project?

1.1-1**Modules** provides ...

1.1-2 Rings supported in a sufficient way

1.1-3 Principal limitation

1.1-4 Ring dictionaries (technical)

1.1-5 The advantages of the outsourcing concept

1.1-6 Does this mean that**homalg** has only algorithms for the generic case?

1.1-7 The principle of least communication (technical)

1.1-8 Frequently asked questions

1.1-1

1.1-2 Rings supported in a sufficient way

1.1-3 Principal limitation

1.1-4 Ring dictionaries (technical)

1.1-5 The advantages of the outsourcing concept

1.1-6 Does this mean that

1.1-7 The principle of least communication (technical)

1.1-8 Frequently asked questions

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 *non*commutative 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