Normaliz backend is broken with double description input

[jplab]

This bug was found while manipulating hyperplane arrangements.

A minimal example to reproduce the bug is:

sage: p1 = Polyhedron(backend='normaliz', base_ring=AA, rays=[(AA(0), AA(0), AA(1)), (AA(0), AA(1), AA(-1)), (AA(1), AA(0), AA(-1))], vertices=[(AA(0), AA(0), AA(0))])
sage: p1
A 3-dimensional polyhedron in AA^3 defined as the convex hull of 1 vertex and 3 rays
sage: -p1
A 3-dimensional polyhedron in AA^3 defined as the convex hull of 1 vertex and 3 lines
sage: p2 = Polyhedron(backend='normaliz', base_ring=AA, rays=[(AA(-1), AA(0), AA(1)), (AA(-1), AA(1), AA(0)), (AA(0), AA(0), AA(-1))], vertices=[(AA(0), AA(0), AA(0))])
sage: p2
A 3-dimensional polyhedron in AA^3 defined as the convex hull of 1 vertex and 3 rays
sage: -p2
A 3-dimensional polyhedron in AA^3 defined as the convex hull of 1 vertex and 3 lines

Looking at dilation it seems that dilation is not the problem, it does the right thing, but the parent.element_class call messes things up.

Notice that changing the base ring to QQ or ZZ or removing the 'normaliz' backend, one does not get the error... This is nasty.

In the hyperplane arrangement, there are some rational regions, and some irrational regions...

CC: @kliem @LaisRast @mkoeppe @tscrim

Component: geometry

Keywords: polytope, backend, normaliz, hyperplane, regions

Author: Jean-Philippe Labbé

Branch/Commit: 83453fb

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/30248

[kliem]

comment:1

Notice that normaliz doesn't use precomputed double description yet (waiting for the package upgrade). I suspect intitialzing from inequaltities doesn't work correctly and there is an even simpler one line example for this.

[kliem]

comment:2

What might be causing it, is passing a generator for the inequalries (in this case you cannot get the error with the normal constructor).

If we iterate twice through it (only for number fields), the second time you obviosly don't get anything, which explains the three lines.

One solution may be to make a tuple out of the generators, once we decided what we dispose in Polyhedron_base.__init__. The main reason for the generators is that we do not want to generate something, which we dispose of a few lines later.

[jplab]

comment:4

Found it.

Line 858 and 859 in backend_normaliz in the method _compute_nmz_data_lists_and_field, which is called by _init_H_representation.

The fact that the base ring is enforced to be AA while the data is really in QQ is taken care of by these 2 lines (normaliz should be used and not Qnormaliz). But! Since dilation ships 2 maps for the Hreps, the data_lists are empty at that point!

Ouff! Ok, I think this shouldn't be too hard to fix.

...this is a sign that this use-case was not really tested... It pops up when one wants to deal with lots of sorts of polyhedra and eventually need to fix a base ring (done in Hyperplane arrangements). Oiii.

[kliem]

comment:5

I implemented a few test suite methods already. If you run a test suite on your polyhedron, does it succeed?

[jplab]

New commits:

83453fb

Fix Hrepr of normaliz for iterators

[jplab]

Commit: 83453fb

[jplab]

Branch: public/30248

[jplab]

comment:7

Replying to @kliem:

I implemented a few test suite methods already. If you run a test suite on your polyhedron, does it succeed?

Yes. It seems so.

[jplab]

Author: Jean-Philippe Labbé

[kliem]

comment:9

Replying to @jplab:

Replying to @kliem:

I implemented a few test suite methods already. If you run a test suite on your polyhedron, does it succeed?

Yes. It seems so.

OK. Then this is a friendly reminder to go on with it.

[jplab]

comment:10

Ping! I think it would be important to have this ticket in the next release...

[tscrim]

Reviewer: Travis Scrimshaw

[tscrim]

comment:11

LGTM.

[vbraun]

Changed branch from public/30248 to 83453fb