One of the key features introduced in version 2.1 is the possibility to write scripts. The scripting language is a slightly enriched version of Perl. This allows to combine all the features of Perl with all the features of `polymake` .

In order to run such a script, just feed it to `polymake` is a single argument. Here we are discussing an example script, which is called show_facets. For this specific example it will be supposed that you have some polytope file my.poly in your working directory, along with the script file (which you can find in the scripts subdirectory of the `polymake` distribution).

The command "polymake show_facets" will then display the graphs of all the facets of my.poly, but each combinatorial type of facet will appear only once.

The script begins with an announcement that we are going to work with the polytope application. It is possible to mix features of several applications, but we are not going to discuss this feature here.

application 'polytope';

Then we define a local scalar variable $p . The function load is given the file name of an existing polytope object. In this example it is supposed to be called my.poly. The second local variable will contain one polytope for each combinatorial type later. It starts its life as an empty list.

my $p=load("my.poly"); my @list=();

The main functionality comes from two nested loops. The outer loop iterates over all the facets of my.poly. To this end it creates a variable $facet which is local within the outer loop. It is initialized with a new polytope object created as (a copy) of the $i -th facet of the input polytope. This is done by the usual client facet, called via the special function Modules::client. Its arguments exactly correspond to the client's usual command line arguments. But, unlike on the command line, the client called from a script does not create a new object on its own. It expects a properly created empty object. Hence the prior call to the object constructor new Apps::polytope::RationalPolytope . The string argument "facet #$i" becomes the name of the object which will be used later by the visualization engine.

AllFacets: for (my $i=0; $i<$p->N_FACETS; ++$i) { my $facet=new Apps::polytope::RationalPolytope("facet #$i"); Modules::client("facet", $facet, $p, $i, "-relabel"); foreach my $other_facet (@list) { next AllFacets if (check_iso($facet, $other_facet)); } push @list, $facet; }

Note that the number of facets of the object $p is addressed as $p->N_FACETS . Likewise you can access all the other polytope properties defined. Depending on their types the properties are returned as scalars (like here) or arrays. Whenever the respective polytope object does not know yet about the property asked for, `polymake`'s rule basis is searched for a rule chain to come up with the desired property -- exactly the way it would do if you ask for that property via the command line interface or from within a client.

The inner loop iterates over all the facet types already found. The current object $facet is checked for combinatorial isomorphy by calling the user function check_iso, that you already saw in the tutorial of the user's guide to application polytope. It wraps nauty. The function returns 1, that is, true, if the two polytopes checked are combinatorially equivalent, and it returns 0 otherwise.

If the inner loop completes then for the sole reason that there was no polytope object in the @list which was combinatorially equivalent to the $facet object. Hence it ends up being added to the @list.

The final line calls the graph visualization method (which usually happens to be forwarded to the JavaView interface) for each single object in the @list. The interactive features of the interface have to be disabled due to the limitation in the current polymake version: It can't support several interactive spring embedders in parallel yet.

static($_->VISUAL_GRAPH) for @list;

The reader is referred to the subdirectory scripts of the distribution for more (partially documented) examples of `polymake` scripts.