Segmentation fault and 2.9.9 vs. 2.9.10

[uramakrishna]

Hello,

Could someone help me on why the following codes segv? I am using 2.9.9. (I think I could be doing something trivially incorrect as for similar simple examples, polymake was running fine a couple of days back.)

Also, I would like to know if 2.9.10 is an actual alpha release. This is because it has been linked from the workshop page, but not the main page.

Thanks again
Ramakrishna

#CODE 1
$a_poly=new Polytope<Rational>(VERTICES=>[
[1,0,0],
[1,-1,0],
[1,-1/4,0],
[1,0,-1],
[1,0,-1/2],
[1,-1/7,-3/7]]);
print $a_poly->N_FACETS;
print $a_poly->FACETS;
print $a_poly->SIMPLE;
print $a_poly->F_VECTOR;
print $a_poly->H_VECTOR;
print $a_poly->VERTICES;
print $a_poly->VISUAL;

#SEGV and EXIT here

#CODE 2
$a_poly=new Polytope<Rational>(VERTICES=>[
[1,0,0],
[1,-1,0],
[1,-1/4,0],
[1,0,-1],
[1,0,-1/2],
[1,-1/7,-3/7]]);
print $a_poly->N_FACETS;
print $a_poly->FACETS;
print $a_poly->SIMPLE;
print $a_poly->F_VECTOR;
print $a_poly->H_VECTOR;
print $a_poly->VERTICES;
print $a_poly->VISUAL;

#SEGV and EXIT here

[uramakrishna]

Sorry, the second code should be the following:

$another_poly=new Polytope<Rational>(VERTICES=>[[-1,0,0], [1,-1,0], [-4,1,0], [1,0,-1], [-2,0,1], [-7,1,3]]);


print $another_poly->N_FACETS;
print $another_poly->FACETS;
print $another_poly->SIMPLE;
print $another_poly->F_VECTOR;
print $another_poly->H_VECTOR;
print $another_poly->VERTICES;
print $another_poly->VISUAL;

#SEGV and EXIT

[paffenholz]

polymake uses homogeneous coordinates for polytopes. So for polymake a polytope is embedded at height 1 in a space one dimension higher (this additional coordinate is the first for each vertex). See here for more details. polymake does not require the leading coordinate to be 1 in the input, your input is instead treated as a cone and intersected with the hyperplane at height one. I think that your vertices in the second example lack the leading homogenization coordinate, it should have been:

Code: Select all

$another_poly=new Polytope<Rational>(VERTICES=>[[1,-1,0,0], [1,1,-1,0], [1,-4,1,0], [1,1,0,-1], [1,-2,0,1], [1,-7,1,3]]);

The points in the first example seem to have the homogenization coordinate. However, if you specify VERTICES in the input of a polytope than you guarantee to polymake that all points you give are really vertices of the polytope. This is never checked! As the list is not irredundant, the input causes the function computing the the dual graph to fail.

If you want to input a list of points and have polymake check which of these are actually vertices of the polytope then you should use POINTS. If you then ask for VERTICES, or some rule requires knowlegde of them, then polymake computes the nonredundant points among POINTS and writes a section VERTICES.

There is a similar distinction between INEQUALITIES and FACETS. The latter has to be irredundant.

As for the two versions: The latest official release is 2.9.9. 2.9.10 comes with several new objects and functions, and we presented these during our workshop. We did not make this an official release as the added functions weren't complete yet and not sufficiently tested. It should however be functional, except for some rare cases. There will (hopefully) be a new official release soon.

[joswig]

Let me add a remark: It is a global design decision that the polymake objects are only functional within their specification. This means a segfault is always possible if you do something wrong (like here).

One could argue that this is inconvenient. However, math says that it is virtually impossible to get a system watertight which has a Turing complete programming language (here: Perl) as a subsystem. So we did not even try. As a benefit a "well-behaved" user does not have to pay for unnecessary checks.