[Up] [Next] [Index]

# 8.1 Introduction

A poset is just a partially ordered set. To display posets reasonably in a generic way we need additional structure. So for XGAP a poset comes in so called levels. At all times in the life of a graphic poset there are only finitely many levels and they are totally ordered, that is for two levels we can always say, which one is ``higher''. The position within the graphic sheet reflects this ordering.

The levels are parametrized by ``level parameters'', which can be any GAP object but must be unique within a graphic poset. A level is always accessed by its level parameter and not by its number!

The vertices in each level are grouped into classes. For example for graphic subgroup lattices vertices in the same class correspond to conjugate subgroups, vertices in the same level have the same size or index in the whole group. The classes within each level are parametrized by ``class parameters'', which can be any GAP object but must be unique within a level. A class within a level is always accessed by its class parameter and not by its number!

The user must supply a partial order for all of his levels. The mechanism to achieve this is the operation `CompareLevels`, which compares two level parameters. The current total order of the levels is always a refinement of the partial order. The user can permute levels, if that does not contradict the partial order defined by `CompareLevels`.

A vertex in the poset that is ``contained in'' another vertex in the poset order (we speak of ``inclusion'' like in the case of subgroup lattices) must always be in a level that is lower on the screen, because there is only a connecting line representing the inclusion. This is achieved by the fact, that inclusions of vertices are communicated to XGAP just by creating an ``edge'' between them. This means, that the vertex in the ``lower'' level lies in the vertex in the ``higher'' level. There must not be edges between vertices in the same level!

The terminology ``vertices'' and ``edges'' comes from the fact, that a graphic poset is just a special case of a graphic graph, where vertices can be placed anywhere in the sheet and edges have nothing to do with inclusion. It is planned that also a graphic graph library is implemented in XGAP but it is not yet operational. However everything which could be done not only for posets but at the same time for graphs is implemented already within the poset package. This explains the usage of ``graph'' in many places where you would otherwise expect ``poset''.

What you have to do to use the graphic poset package is create a graphic poset (a special instance of a graphic sheet), create some levels and perhaps classes within them. Then you can create vertices and edges, to encode the ordering. Everything else is done by the library. See the next section for details about the available operations.

Note that we chose a functional approach for certain decision procedures. This means that for example if you create a vertex and do not specify a position, an operation (`ChoosePosition`) is called to determine the actual position. You can use the generic routines or install your own methods for all of those decisions. In this case you just set a new filter for your posets and overload the generic methods by special routines for objects with your new filter set. You can see this approach in the example in An Example.

[Up] [Next] [Index]