The curious thing is when I print the vertices of $p first, then the triangulation fails.
Why is that?
This behavior is a side effect of the current rules implemented for triangulations, but certainly not the intended behavior. Whenever you assign a triangulation coming from a polytope $c to a separate variable $t=$c->TRIAGULATION, the polytope and this triangulation share the same properties (they share the same object in memory, i.e. $t is a pointer to the triangulation in $c).
Unfortunately, in your second example the triangulation is only created temporarily, as it is created via a rule that says that the coordinates of the triangulation are the vertices of the polytope, and those should not be stored twice. So when the assignment has finished, the triangulation is removed from the cube, leaving you with a rather useless pointer $tri. In the first case everything is fine as polymake choses a rule that computes the facets of the triangulation, and those are stored permanently.
We are currently working on a redesing of triangulations, and this should fix this problem. The quick and simple workaround till then is to ask for a permanent property before assigning the triangulation to a variable. This could e.g. be BALL or FACETS, i.e.
Code: Select all
$c=cube(3);
$c->VERTICES;
$c->TRIANGULATION->FACETS;
$t=$c->TRIANGULATION;
You can also just work with the polytope, accessing properties of the triangulation via $c->TRIANGULATION-><property>.
And is this the proper way to compute a triangulation in polymake?
That depends. If you just need some triangulation of the object then this is the way to go. TRIANGULATION will just contain some arbitrary triangulation on the vertices. If you need more control then you should look into point configuration (created via the object PointConfiguration) and regular subdivisions (see e.g.
here).