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.
xgap manual