Differences

This shows you the differences between two versions of the page.

--- tutorial:polytope_semantics [2011/12/19 14:40] – [Special Cases] paffenholz
+++ user_guide:tutorials:polytope_semantics [2019/01/25 13:40] – ↷ Page moved from user_guide:polytope_semantics to user_guide:tutorials:polytope_semantics oroehrig
@@ Line 3: / Line 3: @@
 ==== General Remarks ====
-The general semantics of a big object in polymake is as follows:  a list of properties describes an equivalence class of mathematical objects.  Often this equivalence class consists of a single element, but this is not necessary.
+The general semantics of a [[https://polymake.org/doku.php/howto/lingo#big_object | big object]] in polymake is as follows: a list of properties describes an equivalence class of mathematical objects.  Often this equivalence class consists of a single element, but this is not necessary.
-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.
+As an example an object of class [[https://polymake.org/release_docs/latest/polytope.html#polytope__Polytope__9|Polytope]] defined by ''VERTICES'' gives such a single element equivalence class.  A typical example of a class with several elements is a polytope given combinatorially, in terms of ''VERTICES_IN_FACETS''.  An extreme case would be a Polytope object defined by ''VOLUME'' only, defining the set of polytopes of all possible dimensions which happen to have that volume.  While this  is not very useful, a similar example would be a Polytope object defined by ''F_VECTOR'' only.  From this it makes sense to derive, e.g., ''N_VERTICES'' or ''H_VECTOR''.
-As an example an object of class Polytope defined by ''VERTICES'' gives such a single element equivalence class.  A typical example of the other kind is a polytope given combinatorially, in terms of ''VERTICES_IN_FACETS''.  An extreme case would be a Polytope object defined by ''VOLUME'' only (defining the set of polytopes of all possible dimensions which happen to have that volume).  While this makes little sense a similar example would be a Polytope object defined by F_VECTOR only.  From this it makes sense to derive, e.g., ''N_VERTICES'' or ''H_VECTOR''.
+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 ''undef''.  This occurs, e.g., if one asks for the ''VERTICES'' of a combinatorially defined polytope.
-If a user asks for a property which cannot be derived this property is set to undef.  This occurs, e.g., if one asks for the ''VERTICES'' of a combinatorially defined polytope.
+To view the list properties that currently constitute your object, you can use the ''properties'' method.
+<code>polytope > $p = new Polytope(POINTS=>[[1,2],[1,3]]);
+polytope > $p->properties;
+name: p
+type: Polytope<Rational>
+POINTS
+2
+3
+CONE_AMBIENT_DIM
+
+</code>
 ===== Objects of type ''Polytope'' =====
@@ Line 18: / Line 32: @@
 Being non-empty is recorded in the property ''FEASIBLE''. This is ''true'' if and only if the polytope is not empty.
+<code>
+polytope > print cube(3)->FEASIBLE;
+</code>
 A non-empty polytope in R^n is encoded as its homogenization in R^{n+1}.  Hence, any non-empty polytope has at least one facet (which may be the far hyperplane [1,0,0,...,0]) and one vertex.
-FIXME: cdd does not return the facet [1,0,0,...] in redundancy checks. It does so in the dual description. As our model should be completely equivalent in the primal and dual description we will try to use the dual description of cdd for redundancy both in the primal and dual case.
 ==== Without coordinates: Combinatorics ====
@@ Line 40: / Line 57: @@
 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 ''FEASIBLE == false''.  Such a polytope is required to have ''VERTICES'' and ''FACETS'' empty.  This is totally different from having ''VERTICES'' or ''FACETS'' undefined (see above).
+An empty polytope is recognized by ''FEASIBLE == false''.  Such a polytope is required to have ''VERTICES'' and ''FACETS'' empty.
+<code>
+polytope > $e = new Polytope(POINTS=>[]);
+polytope > print $e->FEASIBLE;
+polytope > print $e->FACETS;
+</code>
+This is totally different from having ''VERTICES'' or ''FACETS'' undefined (see above).
+<code>
+polytope > $nc = new Polytope(VERTICES_IN_FACETS => cube(2)->VERTICES_IN_FACETS);
+ polytope > print $nc->FACETS;
+polymake:  WARNING: available properties insufficient to compute 'FACETS'
+</code>
 === 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>
+polytope > $z = new Polytope(POINTS=>[[1,2,3]]);
+polytope > print $z->FACETS;
+0 0
+</code>
 ''VERTICES_IN_FACETS'' is a 1-by-1 matrix with a zero entry.  This means that the single vertex does //not// lie on the single facet.
+<code>
+polytope > print $z->VERTICES_IN_FACETS;
+{}
+</code>
 Such a polytope is both simple and simplicial, i.e. it is a simplex.
+<code>
+polytope > print $z->SIMPLICIAL,",",$z->SIMPLE;
+,1
+</code>
 === Zero-dimensional fans ===
-A zero-dimensional fan can e.g. be defined via <code>$f=new PolyhedralFan(RAYS=>[[ ]], MAXIMAL_CONES=>[[]]);</code>
+A zero-dimensional fan can e.g. be defined via
+<code>
+polytope > $f = new fan::PolyhedralFan(RAYS=>[], MAXIMAL_CONES=>[[]]);
+</code>
 ==== Summing Up ====
 For instance we have four possibilities which can occur for ''VERTICES''. The property
-  * does not exist (it is not listed in ''list_properties''): This basically means that the property is not derived/calculated, yet.
+  * does not exist (it is not listed in ''properties''): This basically means that the property is not derived/calculated, yet.
   * exists and is set to ''undef'': Polymake is not able to derive this property with the given properties. The polytope may be empty or not.
   * exists and is empty: So the polytope is empty.
   * exists and is neither set to ''undef'' nor is empty: Our polytope is not empty and the property returns what you expect.