Goto Chapter: Top 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Ind
 [Top of Book]  [Contents]   [Previous Chapter]   [Next Chapter] 

10 Limits and Colimits
 10.1 Specification of Limits and Colimits
 10.2 Enhancing Limit Specifications
 10.3 Functions

10 Limits and Colimits

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.

10.1 Specification of Limits and Colimits

A record specifying a limit in CAP has the following entries:

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:

Semantics is given as follows:

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.

10.2 Enhancing Limit Specifications

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:

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:

10.3 Functions

10.3-1 CAP_INTERNAL_GENERATE_CONVENIENCE_METHODS_FOR_LIMITS
‣ 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.

10.3-2 CAP_INTERNAL_VALIDATE_LIMITS_IN_NAME_RECORD
‣ 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.

 [Top of Book]  [Contents]   [Previous Chapter]   [Next Chapter] 
Goto Chapter: Top 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Ind

generated by GAPDoc2HTML