no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | user_guide:tutorials:latest:polytope_semantics [2023/11/06 10:57] (current) – created - external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ===== Semantics of Cones and Polytopes ===== | ||
+ | |||
+ | ==== General Remarks ==== | ||
+ | |||
+ | The general semantics of a [[user_guide: | ||
+ | |||
+ | As an example an object of class [[documentation: | ||
+ | |||
+ | All big objects are immutable as mathematical objects. This means it is possible to add more properties, but only consistent ones. Ideally, these properties pre-exist (since they are logically derived from the input description of the object), and the rules only make them explicit. If a user asks for a property which cannot be derived, this property is set to '' | ||
+ | |||
+ | To view the list properties that currently constitute your object, you can use the '' | ||
+ | |||
+ | <code perl> | ||
+ | > $p = new Polytope(POINTS=> | ||
+ | > $p-> | ||
+ | name: p | ||
+ | type: Polytope< | ||
+ | |||
+ | CONE_AMBIENT_DIM | ||
+ | 2 | ||
+ | |||
+ | POINTS | ||
+ | 1 2 | ||
+ | 1 3 | ||
+ | |||
+ | </ | ||
+ | ===== Objects of type Polytope ===== | ||
+ | |||
+ | Polytope theory is nice because this is where combinatorics meets metric geometry. For mathematical software dealing with such objects it is necessary to get the semantics straight. Below we describe some pitfalls. | ||
+ | |||
+ | ==== With coordinates: | ||
+ | |||
+ | Being non-empty is recorded in the property '' | ||
+ | |||
+ | <code perl> | ||
+ | > print cube(3)-> | ||
+ | true | ||
+ | </ | ||
+ | A non-empty polytope in $\mathbb R^n$ is encoded as its homogenization in $\mathbb R^{n+1}$. Hence, any non-empty polytope has at least one facet (which may be the far hyperplane $[1, | ||
+ | |||
+ | ==== Without coordinates: | ||
+ | |||
+ | '' | ||
+ | |||
+ | Each property must clearly specify if it depends on the geometry or only on the combinatorics. | ||
+ | |||
+ | ==== Special Cases ==== | ||
+ | |||
+ | Most of what comes below is a consequence of the design decisions explained above. | ||
+ | |||
+ | === Empty polytopes === | ||
+ | |||
+ | With the introduction of the '' | ||
+ | |||
+ | However, this was changed for the reason that often people generate systems of inequalities and then look at the feasible region. Most of the time they obtain a polytope and proceed, but sometimes it fails, and the region is empty. It is therefore necessary to give a definition of the empty polytope (geometrically) which is consistent: | ||
+ | |||
+ | An empty polytope is recognized by '' | ||
+ | |||
+ | <code perl> | ||
+ | > $e = new Polytope(POINTS=> | ||
+ | > print $e-> | ||
+ | false | ||
+ | > print $e-> | ||
+ | </ | ||
+ | This is totally different from having '' | ||
+ | |||
+ | <code perl> | ||
+ | > $nc = new Polytope(VERTICES_IN_FACETS => cube(2)-> | ||
+ | </ | ||
+ | === Zero-dimensional polytopes === | ||
+ | |||
+ | A zero-dimensional polytope is a single point. In our model it has one vertex and one facet (the far hyperplane). | ||
+ | |||
+ | <code perl> | ||
+ | > $z = new Polytope(POINTS=> | ||
+ | > print $z-> | ||
+ | 1 0 0 | ||
+ | </ | ||
+ | '' | ||
+ | |||
+ | <code perl> | ||
+ | > print $z-> | ||
+ | {} | ||
+ | </ | ||
+ | Such a polytope is both simple and simplicial, i.e. it is a simplex. | ||
+ | |||
+ | <code perl> | ||
+ | > print $z-> | ||
+ | true,true | ||
+ | </ | ||
+ | === Zero-dimensional fans === | ||
+ | |||
+ | A zero-dimensional fan can e.g. be defined via | ||
+ | |||
+ | <code perl> | ||
+ | > $f = new fan:: | ||
+ | </ | ||
+ | ==== Summing Up ==== | ||
+ | |||
+ | For instance we have four possibilities which can occur for '' | ||
+ | |||
+ | * does not exist (it is not listed in '' | ||
+ | * exists and is set to '' | ||
+ | * exists and is empty: So the polytope is empty. | ||
+ | * exists and is neither set to '' | ||
+ | |||