"look up" a face in the face lattice of a polyhedron

[gh-kliem]

We implement two methods that look up a face in the face lattice of a polyhedron:

• meet_of_Vrep -- the smallest face containing specified Vrepresentatives
• join_of_facets -- the largest face contained specified facets

This allows an easy answer for ​​https://ask.sagemath.org/question/34485/what-is-the-most-efficient-way-to-look-up-a-face-in-the-face-lattice-of-a-polyhedron/#50965

[gh-kliem]

Last 10 new commits:

​295039a	documentation
​d36da4a	coverage and small improvement
​2d0f0d9	method `reset` for the face iterator
​6d99a4c	typo
​5711f6b	method `ignore_subsets`
​f6633bd	method current and fix for reset
​e8c17c3	join_of_Vrep and meet_of_facets for face iterator
​b371a73	expose in combinatorial_polyhedron
​954b5c8	raise index error for index error
​521f9e0	expose in Polyhedron_base

[gh-kliem]

There are failing tests. I would wait until the dependices are taken care of to make things work again.

[gh-kliem]

New commits:

​19d2742	join_of_Vrep and meet_of_facets for face iterator
​c5c17ff	account for changes in the newest develop
​7a4b950	expose in combinatorial_polyhedron
​f108b06	raise index error for index error; fix doctests
​a69ba9f	expose in Polyhedron_base
​a6f53af	fix doctests

[gh-kliem]

I want to redesign some of the setup before making everything more complicated.

More precisely, creating strucutures face_struct and faces_list_struct that take care of the details. Then this overly long argument list of get_next_level will just reduce to three arguments or so. This would also make future changes easier including the transition to bitsets.pxi.

[gh-kliem]

New commits:

​2a14433	join_of_Vrep and meet_of_facets for face iterator
​530d85c	expose in combinatorial_polyhedron
​73a8be1	raise index error for index error; fix doctests
​c7ce411	expose in Polyhedron_base
​7e0a25e	fix doctests

[mkoeppe]

Some quick comments:

• "The offset is taken correctly" - what's that?
• Change "reseted" to "reset"
• "In case of an unbounded polyhedron" -> "In the case ..."

[gh-kliem]

I discovered a bug by accident:

sage: P = polytopes.permutahedron(3, backend='cdd')                                                                                                                                 
sage: [x.ambient_Hrepresentation() for x in P.facets()]                                                                                                                             
[(An inequality (1, 1, 0) x - 3 >= 0, An inequality (1, 0, 1) x - 3 >= 0),
 (An inequality (1, 1, 0) x - 3 >= 0, An inequality (1, 0, 0) x - 1 >= 0),
 (An inequality (1, 1, 0) x - 3 >= 0, An inequality (0, 1, 1) x - 3 >= 0),
 (An inequality (1, 1, 0) x - 3 >= 0, An inequality (0, 1, 0) x - 1 >= 0),
 (An inequality (1, 1, 0) x - 3 >= 0, An inequality (0, 0, 1) x - 1 >= 0),
 (An inequality (1, 1, 0) x - 3 >= 0, An equation (1, 1, 1) x - 6 == 0)]

The problem is that the backend cdd doesn't put equations in a stable place, which my code assumed. It depends whether you initialize from Vrep or from Hrep I guess.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​69740e7

improved documentation

[mkoeppe]

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.