Changes between Initial Version and Version 1 of Ticket #29683, comment 39
- Timestamp:
- 05/18/21 05:59:19 (12 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #29683, comment 39
initial v1 1 1 Now consider `Polyhedron_base`. 2 2 3 To be honest, I often forget what `join_of_..` and `meet_of_...` mean in this class. I propose to rename them. How do `def face_as_union_of_Vrep(self, *Vrepresentatives)` and `def face_as_intersection_of_Hrep(self, *Hrepresentatives)` sound? I would prefer that the two functions are sort of symmetric. Lines and equations are allowed, but are simply ignored when passing to `self.face_generator()`.3 To be honest, I often forget what `join_of_..` and `meet_of_...` mean in this class. I propose to rename them. How do `def least_common_superface_of_Vrep(self, *Vrepresentatives)` and `def greatest_common_subface_of_Hrep(self, *Hrepresentatives)` sound? I would prefer that the two functions are sort of symmetric. Lines and equations are allowed, but are simply ignored when passing to `self.face_generator()`. 4 4 5 5 In the Hrepresentation, `ppl` backend puts equations first, and `field`, `cdd`, `normaliz` put inequalities first. (I was not able to install `polymake` backend.) Thus, the offset treatment seems needed.