user_guide:tutorials:properties

This tutorial is probably also available as a Jupyter notebook in the demo folder in the polymake source and on github.

Different versions of this tutorial: latest release, release 4.11, release 4.10, release 4.9, release 4.8, release 4.7, release 4.6, release 4.5, release 4.4, release 4.3, release 4.2, release 4.1, release 4.0, release 3.6, nightly master

This is an old revision of the document!


Objects, Properties and Rules

In polymake, there is two kinds of objects. A Big Object models a complex mathematical concept, like a Polytope or a SimplicialComplex, while a small object is an instance of one of the many data types commonly used in computer science, like Integers, Matrices, Sets or Maps. A big object consists of a collection of other objects (big or small) describing it, called properties, and functions to compute more properties from the ones already known, called production rules.

To find out the type of an object $c, enter

print $c->type->full_name;

To get a more detailed explanation of the polymake object model and properties, check out the scripting guide.

You can save polymake objects to disc, as explained here.

Each (big) object has a list of properties of various types. When an object is 'born' it comes with an initial list of properties, and all other properties will be derived from those. Let's look at example from the polytope application. The following creates a 3-dimensional cube:

polytope > $c=cube(3);

To find out what the initial set of properties is, use the list_properties method. It returns an array of strings. The extra code is just there to print this list nicely.

polytope > print join(", ", $c->list_properties);
CONE_AMBIENT_DIM, CONE_DIM, FACETS, AFFINE_HULL, VERTICES_IN_FACETS, BOUNDED

To see what a property contains, use the syntax:

polytope > print $c->FACETS;

1 1 0 0
1 -1 0 0
1 0 1 0
1 0 -1 0
1 0 0 1
1 0 0 -1

You can also get the content of all properties using the properties method:

polytope > $c->properties;
name: c
type: Polytope<Rational>
description: cube of dimension 3


CONE_AMBIENT_DIM
4

CONE_DIM
4

FACETS
1 1 0 0
1 -1 0 0
1 0 1 0
1 0 -1 0
1 0 0 1
1 0 0 -1


AFFINE_HULL


VERTICES_IN_FACETS
{0 2 4 6}
{1 3 5 7}
{0 1 4 5}
{2 3 6 7}
{0 1 2 3}
{4 5 6 7}


BOUNDED
1

The object is changed if we ask for a property which has not been computed before.

polytope > print $c->VERTICES;
1 -1 -1 -1
1 1 -1 -1
1 -1 1 -1
1 1 1 -1
1 -1 -1 1
1 1 -1 1
1 -1 1 1
1 1 1 1

polytope > print join(", ", $c->list_properties);
CONE_AMBIENT_DIM, CONE_DIM, FACETS, AFFINE_HULL, VERTICES_IN_FACETS, BOUNDED, FEASIBLE, POINTED, N_FACETS, FULL_DIM, N_VERTICES, VERTICES, LINEALITY_SPACE

The property VERTICES was added, but a few others were computed on the way, too. polymake applied a sequence of production rules that add new properties to the object that can be computed from the properties the object already posesses.

What properties can be computed for a given object depends on the set of rules defined for it. Here is a short sequence of commands which lets you find out.

polytope> $t=$c->type->full_name;
polytope> print join(", ", sorted_uniq(sort { $a cmp $b } map { keys %{$_->properties} } $t, @{$t->super}));

Instead of showing the (lengthy) enumeration have a look at the documentation for a complete list of properties known for objects of the application polytope.

Schedules

You may wonder what sequence of rules led to the computation of a property you request. There usually are several mathematical ways to compute a property. polymake uses a nice scheduling algorithm to find the most efficient procedure, and you can look at what it returns.

Suppose we want to see which sequence of rules leads to the computation of the F_VECTOR.

polytope > $schedule=$c->get_schedule("F_VECTOR");
polytope > print join("\n", $schedule->list);
HASSE_DIAGRAM : RAYS_IN_FACETS
F_VECTOR : HASSE_DIAGRAM

So if you ask for the f-vector, polymake will first compute the Hasse diagram from the vertex-facet-incidences, and then compute the f-vector form the Hasse diagram. Applying the schedule to the object yields the same as asking for the property right away:

polytope > $schedule->apply($c);
polytope > print join(", ", $c->list_properties);
POLYTOPE_AMBIENT_DIM, POLYTOPE_DIM, FACETS, VERTICES_IN_FACETS, BOUNDED, HASSE_DIAGRAM, F_VECTOR

As you can see, the things polymake needed to compute in order to get to the f-vector are stored in the object as well, so you don't have to recompute them later.

If you're interested, read more about rule scheduling in the scripting guide and the article on writing rules yourself.

  • user_guide/tutorials/properties.1549902274.txt.gz
  • Last modified: 2019/02/11 16:24
  • by oroehrig