This section describes the support for limits and colimits in CAP. All notions defined in the following are considered with regard to limits, not colimits, except if explicitly stated otherwise. In particular, the diagram specification specifies a diagram over which the limit is taken. The colimit in turn is taken over the opposite diagram.
A record specifying a limit in CAP has the following entries:
object_specification: see below
morphism_specifiation: see below
limit_object_name: the name of the method returning the limit object, e.g. DirectProduct or KernelObject
limit_projection_name (optional): the name of the method returning the projection(s) from the limit object, e.g. ProjectionInFactorOfDirectProduct or KernelEmbedding. Defaults to Concatenation( "ProjectionInFactorOf", limit_object_name ).
limit_universal_morphism_name (optional): the name of the method returning the universal morphism into the limit object, e.g. UniversalMorphismIntoDirectProduct or KernelLift. Defaults to Concatenation( "UniversalMorphismInto", limit_object_name ).
colimit_object_name: the name of the method returning the colimit object, e.g. Coproduct or CokernelObject
colimit_injection_name (optional): the name of the method returning the injection(s) into the colimit object, e.g. InjectionOfCofactorOfCoproduct or CokernelProjection. Defaults to Concatenation( "InjectionOfCofactorOf", colimit_object_name ).
colimit_universal_morphism_name (optional): the name of the method returning the universal morphism from the colimit object, e.g. UniversalMorphismFromCoproduct or CokernelColift. Defaults to Concatenation( "UniversalMorphismFrom", colimit_object_name ).
limit_object_name and colimit_object_name can be the same, e.g. for DirectSum or ZeroObject.
The object_specification and morphism_specification together specify the shape of the diagram defining the limit or colimit. The syntax is the following:
object_specification is a list of strings. Only the strings "fixedobject" and "varobject" are allowed as entries of the list. These are called "types" in the following.
morphism_specification is a list of triples. The first and third entry of a triple are integers greater or equal to 1 and less or equal to Length( object_specification ). The second entry is one of the following strings: "fixedmorphism", "varmorphism", "zeromorphism". This entry is called "type" in the following.
Semantics is given as follows:
The type "fixedobject" specifies a single object. The type "varobject" specifies arbitrarily many objects.
The first and the third entry of a triple specify the source and range of a morphism (or multiple morphisms) encoded by the position in object_specification respectively. The type "fixedmorphism" specifies a single morphism. In this case, source and range can only be of type "fixedobject", not of type "varobject". The type "varmorphism" specifies arbitrarily many morphisms. In this case, if the source (resp. range) is of type "fixedobject" all the morphisms must have the same source (resp. range). On the contrary, if the source (resp. range) is of the type "varobject", the objects correspond one-to-one to the sources (resp. ranges) of the morphisms. The type "zeromorphism" is currently ignored but will be endowed with semantics in the future.
For example, a FiberProduct diagram consists of arbitrarily many morphisms which have arbitrary sources but the same common range. This can be expressed as follows:
rec( object_specification := [ "fixedobject", "varobject" ], morphism_specification := [ [ 2, "varmorphism", 1 ] ], limit_object_name := "FiberProduct", colimit_object_name := "Pushout", )
Note that not all diagrams which can be expressed with the above are actually supported. For now, at most one unbound object (see below for the definition of "unbound") may be of type "varobject", and if there is such an unbound object it must be the last one among the unbound objects. Similarly, at most one unbound morphism may be of type "varmorphism", and if there is such an unbound morphism it must be the last one among the unbound morphisms.
The function CAP_INTERNAL_ENHANCE_NAME_RECORD_LIMITS takes a list of limits (given by records as explained above), and computes some additional properties. For example, the number of so-called unbound objects, unbound morphisms and (non-)targets is computed. The term "unbound" signifies that for creating a concrete diagram, these objects or morphisms have to be specified by the user because they cannot be derived by CAP:
Unbound morphisms are the triples which are of type "fixedmorphism" or "varmorphism".
Unbound objects are the objects which are not source or range of an unbound morphism.
Finally, targets are the objects which are not the range of a morphism. These are of interest for the following reason: for limits, only projections into targets are relevant because the projections into other objects can simply be computed by composition. Similarly, one only has to give morphisms into these targets to compute a universal morphism.
The number of unbound objects, unbound morphisms and (non-)targets is expressed by the integers 0, 1 and 2:
0: no such object/morphism/target exists
1: there exists exactly one such object/target of type "fixedobject" respectively exactly one such morphism of type "fixedmorphism"
2: else
‣ CAP_INTERNAL_GENERATE_CONVENIENCE_METHODS_FOR_LIMITS( package_name, method_name_record, limits ) | ( function ) |
This function takes a package name, a method name record and a list of enhanced limits, and generates convenience methods for the limits as a string of GAP code. The result is compared to the content of the file package_name/gap/LimitConvenienceOutput.gi. If a difference is found, a warning is raised and the generated string is written to a temporary file for manual inspection.
‣ CAP_INTERNAL_VALIDATE_LIMITS_IN_NAME_RECORD( method_name_record, limits ) | ( function ) |
This function takes a method name record and a list of enhanced limits, and validates the entries of the method name record. Prefunctions, full prefunctions and postfunctions are excluded from the validation.
generated by GAPDoc2HTML