chap1.txt

  
  1 Introduction
  
  
  1.1 What is the role of the Modules package in the homalg project?
  
  
  1.1-1 Modules provides ...
  
  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.
  
  
  1.1-2 Rings supported in a sufficient way
  
  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 (--> 1.1-3).
  
  
  1.1-3 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].
  
  
  1.1-4 Ring dictionaries (technical)
  
  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.
  
  
  1.1-5 The advantages of the outsourcing concept
  
  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.
  
  
  1.1-6 Does this mean that homalg has only algorithms for the generic case?
  
  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.
  
  
  1.1-7 The principle of least communication (technical)
  
  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.
  
  
  1.1-8 Frequently asked questions
  
      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 (--> 1) 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.
  
  
  1.2 This manual
  
  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.