Quellcodebibliothek Statistik Leitseite products/Sources/formale Sprachen/GAP/pkg/modules/doc/   (Algebra von RWTH Aachen Version 4.15.1©)  Datei vom 22.11.2024 mit Größe 10 kB image not shown  

Quelle  intro.xml   Sprache: XML

 
<?xml version="1.0" encoding="UTF-8"?>

<!-- 

  intro.xml            Modules package documentation

         Copyright (C) 2007-2009, Mohamed Barakat, RWTH-Aachen

This chapter gives a short introduction and explains the philosophy
behind the package.

-->


<Chapter Label="intro">
<Heading>Introduction</Heading>

<Section Label="Modules-role">
<Heading>What is the role of the &Modules; package in the &homalg; project?</Heading>

<Subsection Label="Modules-provides">
<Heading>&Modules; provides ...</Heading>

It provides procedures to construct basic objects in homological algebra:
<List>
  <Item>modules (generators, relations)</Item>
  <Item>submodules (as images of maps)</Item>
  <Item>maps</Item>
</List>
Beside these so-called constructors &Modules;
provides <Alt Only="HTML"><Ref Text="operations"
Sect="Operations and Methods" BookName="Tutorial"/></Alt>
<Alt Not="HTML"><E>operations</E></Alt> to perform computations with
these objects. The list of operations includes:
<List>
  <Item>resolution of modules</Item>
  <Item>images of maps</Item>
  <Item>the functors <C>Hom</C> and <C>TensorProduct</C>
  (<C>Ext</C> and <C>Tor</C> are then provided by &homalg;)</Item>
  <Item>test if a module is torsion-free, reflexive, projective,
    stably free, free, pure</Item>
  <Item>determine the rank, grade, projective dimension, degree
    of torsion-freeness, and codegree of purity of a module</Item>
</List>

Using the philosophy of &GAP4;, one or
more <Alt Only="HTML"><Ref Text="methods" Sect="Operations and Methods"
BookName="Tutorial"/></Alt> <Alt Not="HTML">methods</Alt>
are
<Alt Only="HTML"><Ref Text="installed" Sect="Method Installation"
BookName="Reference"/></Alt>
<Alt Not="HTML"><E>installed</E></Alt> for each operation, depending
on <Alt Only="HTML"><Ref Text="properties" Sect="Properties"
BookName="Tutorial"/></Alt> <Alt Not="HTML"><E>properties</E></Alt>
and <Alt Only="HTML"><Ref Text="attributes" Sect="attributes"
BookName="Tutorial"/></Alt> <Alt Not="HTML"><E>attributes</E></Alt> of
these objects. These properties and attributes can themselves be
computed by methods installed for this purpose.

</Subsection>

<Subsection Label="SufficientSupport">
<Heading>Rings supported in a sufficient way</Heading>

Through out this manual the following terminology is used.  We say
that a computer algebra system <Q>sufficiently supports</Q> a
ring <M>R</M>, if it contains procedures to effectively solve
one-sided inhomogeneous linear systems <M>XA=B</M> and <M>AX=B</M>
with coefficients over <M>R</M> (&see; <Ref Label="Modules-limitation"
Text="Principal limitation"/>).

</Subsection>

<Subsection Label="Modules-limitation">
<Heading>Principal limitation</Heading>

Note that the solution space of the one-sided finite dimensional
system <M>YA=0</M> (resp. <M>AY=0</M>) over a left (resp. right)
noetherian ring <M>R</M> is a finitely generated left
(resp. right) <M>R</M>-module, even if <M>R</M> is not
commutative. The solution space of the linear system <M>X_1 A_1 + A_2
X_2 + A_3 X_3 A_4=0</M> is in general not an <M>R</M>-module, and
worse, in general not finitely generated over the center
of <M>R</M>. &Modules; can only handle homological problems that lead
to <E>one sided</E> <E>finite dimensional</E> homogeneous or
inhomogeneous systems over the underlying ring <M>R</M>. Such problems
are called problems of <E>finite type</E> over <M>R</M>. Typically,
the computation of <C>Hom</C><M>(M,N)</M> of two (even) finitely
generated modules over a <E>non</E>commutative ring <M>R</M> is
generally <E>not</E> of finite type over <M>R</M>, unless at least one
of the two modules is an <M>R</M>-bimodule. Also note that over a
commutative ring any linear system can be easily brought to a
one-sided form. For more details see <Cite Key="BR"/>. <P/>

</Subsection>

<Subsection Label="Modules-dict">
<Heading>Ring dictionaries (technical)</Heading>

&Modules; uses the so-called <C>homalgTable</C>, which is stored in the
ring, to know how to delegate the necessary matrix operations.
I.e. the <C>homalgTable</C> 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 <C>homalgTable</C>. 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. <P/>

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. <P/>

</Subsection>

<Subsection Label="outsource">
<Heading>The advantages of the outsourcing concept</Heading>

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 (&see; Appendix <Ref BookName="homalg"
Sect="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.

</Subsection>

<Subsection Label="also-special">
<Heading>Does this mean that &homalg; has only algorithms for the generic case?</Heading>

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
(&see; Appendix <Ref BookName="homalg" Sect="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.

</Subsection>

<Subsection Label="least-communication">
<Heading>The principle of least communication (technical)</Heading>

Linking different systems can also be highly problematic. The
following two points are often among the major sources of
difficulties:
<List>
  <Item>Different systems use different languages:<Br/> 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.</Item>
  <Item>Data has to be transferred from one system to another:<Br/>
    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.</Item>
</List>

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. <P/>

The existence of such a clear cut is certainly to some extent due to
the special nature of homological computations.

</Subsection>

<Subsection Label="FAQ">
<Heading>Frequently asked questions</Heading>

<List>
  <Item><B>Q</B>: Does outsourcing the matrices mean that &Modules; is
    able to compute spectral sequences, for example, without ever
    seeing the matrices involved in the computation?<Br/><Br/> A:
    Yes.</Item>
  <Item><B>Q</B>: Can &Modules; profit from the implementation of
    homological constructions like <C>Hom</C>, <C>Ext</C>, ... in
    &Singular;?<Br/><Br/> A: No. This is for a lot of reasons
    incompatible with the <Alt Only="HTML"><Ref Text="idea and design" Label="intro"/></Alt>
    <Alt Not="HTML">idea and design (&see; <Ref Label="intro"/>)</Alt>
    of &Modules;.</Item>
  <Item><B>Q</B>: Are the external systems involved in the higher
    algorithms?<Br/><Br/> 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;.</Item>
  <Item><B>Q</B>: Do developers of packages building upon &Modules;
    need to know anything about the communication with the external
    systems?<Br/><Br/> 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;.</Item>
</List>

</Subsection>

</Section>

<Section Label="overview">
<Heading>This manual</Heading>

Chapter <Ref Chap="install"/> describes the installation of this
package, while Chapter <Ref Chap="QuickStart"/> 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 (&see; <Ref Label="Modules-provides"/>) with its
constructors, properties, attributes, and operations.

<!--
Finally, Chapter <Ref Chap="examples"/> shows some instructive
examples for the usage of this package.
-->


</Section>

<!-- ############################################################ -->

</Chapter>

<!--  LocalWords:  ExamplesForHomalg
 -->

95%


¤ Dauer der Verarbeitung: 0.2 Sekunden  (vorverarbeitet)  ¤

*© Formatika GbR, Deutschland






Wurzel

Suchen

Beweissystem der NASA

Beweissystem Isabelle

NIST Cobol Testsuite

Cephes Mathematical Library

Wiener Entwicklungsmethode

Haftungshinweis

Die Informationen auf dieser Webseite wurden nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit, noch Qualität der bereit gestellten Informationen zugesichert.

Bemerkung:

Die farbliche Syntaxdarstellung ist noch experimentell.