Cannot plot non-strictly convex cones

[vbraun]

Plotting cones relies on the cone's face lattice:

sage: halfspace = Cone([(1,0,0), (0,1,0), (-1,-1,0), (0,0,1)])
sage: halfspace.plot()
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)

/home/vbraun/opt/sage-4.6/devel/sage-main/<ipython console> in <module>()

/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/sage/geometry/cone.pyc in plot(self, **options)
   2623         if self.dim() >= 2:
   2624             # Modify wall labels to match the ambient cone or fan too.
-> 2625             walls = self.faces(2)
   2626             try:
   2627                 ambient_walls = self.ambient().faces(2)

/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/sage/geometry/cone.pyc in faces(self, dim, codim)
   2015         if "_faces" not in self.__dict__:
   2016             self._faces = tuple(self._sort_faces(e.element for e in level)
-> 2017                                 for level in self.face_lattice().level_sets())
   2018             # To avoid duplication and ensure order consistency
   2019             if self.dim() > 0:

/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/sage/geometry/cone.pyc in face_lattice(self)
   1854                 # We need to compute face lattice on our own
   1855                 if not self.is_strictly_convex():
-> 1856                     raise NotImplementedError("face lattice is currently "
   1857                                 "implemented only for strictly convex cones!")
   1858                 def ConeFace(rays, facets):

NotImplementedError: face lattice is currently implemented only for strictly convex cones!

Is there any reason for why we can't compute the face lattice of a non-strictly convex cone? If there is, we might want to still plot something reasonable in that case...

[novoselt]

Originally there was no code to compute face lattices of non-strictly convex cones, but with your recent modifications it will be easy to fix.

Plotting code that I wrote will not immediately work for such cases anyway, but again it should not be terribly difficult to fix, I just was more concerned with plotting fans.

Will work on it!

P.S. Since it was due to NotImplemented, I consider this ticket an enhancement ;-)

[novoselt]

I am thinking of:

• allowing cone.faces(d) to accept any d and return an empty tuple if there are no faces of dimension d;
• returning a tuple of non-empty tuples as the output of cone.faces(), i.e. for a half-space it will be just ((plane,), (half-space,)) instead of ((), (), (plane,), (half-space,)) where the d-th tuple contains faces of dimension d.

Thoughts?

[novoselt]

I attached the first development version. face_lattice should work for any cone now and there are a few small corrections in other places. Definitely needs more work!-)

[vbraun]

Replying to novoselt:

I am thinking of:

• allowing cone.faces(d) to accept any d and return an empty tuple if there are no faces of dimension d;
• returning a tuple of non-empty tuples as the output of cone.faces()

both sound good to me!

[novoselt]

Great! Done! Refreshed patch should deal fine with faces in all cases, all old doctests pass and I added a couple for non-strictly convex cones - there was an issue originally for "totally non-strictly conex" cones like a plane, that's why there is DiGraph(1) in Hasse_diagram.

Regarding the plots. Let's take, e.g. a half-plane generated by vectors (1,0), (1,1), (0,1), (-1,0). I propose that its plot will look exactly like the plot of the fan with these generators except that two middle vectors will be plotted as generators, but there will be no rays in their direction extending to the boundary of the plot (labels still will be places on the boundary out of colored regions). The label for the half-plane itself will be randomly placed between two consecutive generators - this way it will be inside and will not get crossed by one of the internal generators.

[novoselt]

OK, it remains to make the default "round" mode work and reposition labels of non-strictly convex 2-d walls.

[novoselt]

Now plotting should work in all modes.

Wall labels will be positioned between two generators that generate the plane of the wall. This will result in OK placement for automatically adjusted generators (i.e. when half-planes are generated by 3 rays and planes by 4). If the user has forced (via check=False option) other generators, they can potentially cross labels, in which case this user should place labels manually.

I have switched toric_plotter to using RDF instead of RR since the first seems to be a little faster.

[novoselt]

Made user's radius more important (new code block in ToricPlotter.__init__), so that it is possible to make it small even if it cuts off some generators.

[novoselt]

Depends on #9972.

[vbraun]

Nice! Tested against sage-4.6.1alpha3