Opened 4 years ago
Last modified 7 months ago
#27063 closed task
Polyhedron: let CombinatorialPolyhedron do all combinatorial calculations — at Version 14
Reported by:  ghkliem  Owned by:  

Priority:  major  Milestone:  sageduplicate/invalid/wontfix 
Component:  geometry  Keywords:  polyhedron, face lattice 
Cc:  JeanPhilippe Labbé, Matthias Köppe  Merged in:  
Authors:  Jonathan Kliem  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  public/27063 (Commits, GitHub, GitLab)  Commit:  c4ccf860ba2906123bd20b4e3a49ad3e94ca7bdb 
Dependencies:  #28621  Stopgaps: 
Description (last modified by )
In #26887 we created a new class, that handles the calculations depending only on the combinatorial type more quickly.
The goal of this ticket is to make use of this class through Polyhedron_base
.
Add:
 #28621:
combinatorial_polyhedron
,  a face iterator,
 facet graph
Replace:
 #28625:
f_vector
, faces
,graph
/vertex_graph
,vertex_adjacency_matrix
,vertex_digraph
facet_adjacency_matrix
,face_lattice
.
Finally, it might make sense to move code to CombinatorialPolyhedron
. E.g. is_prism
can be checked there and should only be checked there to avoid code duplication.
Change History (14)
comment:1 Changed 4 years ago by
Milestone:  sage8.6 → sage8.7 

comment:2 Changed 4 years ago by
Milestone:  sage8.7 → sage8.8 

comment:3 Changed 3 years ago by
Authors:  → Jonathan Kliem 

Branch:  → public/27063 
Commit:  → 25407f852d524693571b97e1d26e4fdd264b51fe 
Dependencies:  #26887 → #26887, #27987 
Description:  modified (diff) 
Last 10 new commits:
9b69f50  added documentation and examples to each module

4e8fd8c  correct hyperlinks

72ac3b0  documentation fix

611099f  Do not iterate twice for CombinatorialPolyhedron.facets()

d38e130  added combinatorial face

ca60665  improved docstring in list_of_all_faces

abe00b6  fixed small issues

8765313  A number of small edits.

d419d72  Merge branch 'public/26887' of git://trac.sagemath.org/sage into public/27063

25407f8  faces, f_vector, vertex_graph, vertex_digraph, neighborliness now use CombinatorialPolyhedron

comment:4 Changed 3 years ago by
Commit:  25407f852d524693571b97e1d26e4fdd264b51fe → c4ccf860ba2906123bd20b4e3a49ad3e94ca7bdb 

Branch pushed to git repo; I updated commit sha1. New commits:
c4ccf86  face lattice by CombinatorialPolyhedron

comment:5 Changed 3 years ago by
Milestone:  sage8.8 

As the Sage8.8 release milestone is pending, we should delete the sage8.8 milestone for tickets that are not actively being worked on or that still require significant work to move forward. If you feel that this ticket should be included in the next Sage release at the soonest please set its milestone to the next release milestone (sage8.9).
comment:6 Changed 3 years ago by
Milestone:  → sage8.9 

comment:7 followup: 8 Changed 3 years ago by
Milestone:  sage8.9 → sagepending 

Concerning the .faces()
method. Currently, .iter_face
only deals with proper faces. ... is that the intended behavior?
From an old list (so maybe some of them are renamed), I also saw the following methods make use of .face_lattice
, and probably would benefit from the combinatorial polyhedra:
 adjacency_matrix
 facet_adjacency_matrix
 facial_adjacencies
 is_simple
 vertex_adjacency_matrix
It would be nice to make a thorough checking of which methods make use of "old style face lattice" things. It would be bad to not make the whole Polyhedron
objects not benefit from this new class...
comment:8 followup: 9 Changed 3 years ago by
Replying to jipilab:
Concerning the
.faces()
method. Currently,.iter_face
only deals with proper faces. ... is that the intended behavior?
This is simply, because my method of intersecting faces and avoiding double counting has no guarantee to hit the empty face in the unbounded case. So one has to manually add it anyway. I would prefer leaving it like this in FaceIterator
. But I can see that one wants to add those two extra faces (or only one for the empty polyhedron) when wrapping the class.
From an old list (so maybe some of them are renamed), I also saw the following methods make use of
.face_lattice
, and probably would benefit from the combinatorial polyhedra:
 adjacency_matrix
 facet_adjacency_matrix
 facial_adjacencies
what does it do, I can't find it
 is_simple
not anymore
 vertex_adjacency_matrix
It would be nice to make a thorough checking of which methods make use of "old style face lattice" things. It would be bad to not make the whole
Polyhedron
objects not benefit from this new class...
Yes, that's my plan. If I actually go through with it and make CombinatorialPolyhedron
a parent of Polyhedron_base
, as was proposed in #10777, then CombinatorialPolyhedron
should do all calculations that depend only on the incidence matrix.
comment:9 followup: 10 Changed 3 years ago by
Replying to ghkliem:
Replying to jipilab:
Concerning the
.faces()
method. Currently,.iter_face
only deals with proper faces. ... is that the intended behavior?This is simply, because my method of intersecting faces and avoiding double counting has no guarantee to hit the empty face in the unbounded case. So one has to manually add it anyway. I would prefer leaving it like this in
FaceIterator
. But I can see that one wants to add those two extra faces (or only one for the empty polyhedron) when wrapping the class.
Sounds good.
From an old list (so maybe some of them are renamed), I also saw the following methods make use of
.face_lattice
, and probably would benefit from the combinatorial polyhedra:
 adjacency_matrix
 facet_adjacency_matrix
 facial_adjacencies
what does it do, I can't find it
Then, fine.
 is_simple
not anymore
Good
 vertex_adjacency_matrix
It would be nice to make a thorough checking of which methods make use of "old style face lattice" things. It would be bad to not make the whole
Polyhedron
objects not benefit from this new class...Yes, that's my plan. If I actually go through with it and make
CombinatorialPolyhedron
a parent ofPolyhedron_base
, as was proposed in #10777, thenCombinatorialPolyhedron
should do all calculations that depend only on the incidence matrix.
Great! Then, one should also take care to not let the Polyhedron_base
overwrite them, but duh... I'm sure you know what your doing... :)
comment:10 followup: 11 Changed 3 years ago by
Replying to jipilab:
Great! Then, one should also take care to not let the
Polyhedron_base
overwrite them, but duh... I'm sure you know what your doing... :)
Well, you can always access overwritten methods using super
.
Does it make sense to leave a method as e.g. simple
in Polyhedron_base
just to have a more specific docstring? Otherwise we would eventually end up with docstrings gathering all examples from Polyhedron
, LatticePolytope
and Cone
.
comment:11 Changed 3 years ago by
Replying to ghkliem:
Replying to jipilab:
Great! Then, one should also take care to not let the
Polyhedron_base
overwrite them, but duh... I'm sure you know what your doing... :)Well, you can always access overwritten methods using
super
.Does it make sense to leave a method as e.g.
simple
inPolyhedron_base
just to have a more specific docstring? Otherwise we would eventually end up with docstrings gathering all examples fromPolyhedron
,LatticePolytope
andCone
.
I am not 100% sure about this. I believe that the method would stay in Polyhedron_base
(think about the documentation online too) because one expects to see it there (and one does not directly think about the CombinatorialPolyhedron
class directly, maybe) and the method would be only a couple of lines long and calling the combinatorial algorithm using super
with the appropriate parameters.
On the long run, CombinatorialPolyhedron
will contain the bulk of codes that strictly makes use of combinatorial data and Polyhedron_base
things that use the geometry.
Further, concerning the present ticket, I believe it would make sense to make it a preparation ticket. Then each method would have 1 ticket. This way the changes will be more manageable.
Another open question: currently how is the relation between a Polyhedron
object and a CombinatorialPolyhedron
object? I guess that as of now, since the double description is computed by default, it is worth maybe creating the combinatorial counter part as an attribute and make it accessible via a method say named .combinatorial_polyhedron
. This might make it easier to then transfer the computations to the combinatorial type.
When I create a combinatorial polyhedron from a polyhedron, it seems to keep the polyhedron object. Ideally, it would be nice to be able to go back and forth between them like it is for LP
and Polyhedron
(okay, it is not fully bakc and forth but still).
... and it would be nice if the methods of CombinatorialPolyhedron
have exactly the same names for the same things H_representation
vs Hrepr
.
comment:12 Changed 3 years ago by
Ok, this is a bunch of things. I realized that at some point it makes sense to create some sort of meta ticket for CombinatorialPolyhedron
, also I realize that this ticket is more an agenda than anything else.
First of all, we should figure out, whether Polyhedron
shall inherit from CombinatorialPolyhedron
as a base class or whether its better to have it as a (lazy) method available.
Having it as a base class was proposed in #10777.
Maybe I should start a discussion on sagedevel to see what (interested) people think.
comment:13 Changed 3 years ago by
Dependencies:  #26887, #27987 → #28621 

Description:  modified (diff) 
Status:  new → needs_review 
comment:14 Changed 3 years ago by
Description:  modified (diff) 

Retarging tickets optimistically to the next milestone. If you are responsible for this ticket (either its reporter or owner) and don't believe you are likely to complete this ticket before the next release (8.7) please retarget this ticket's milestone to sagepending or sagewishlist.