Hi Sébastien, Let me first say I am glad you are working on and thinking about this.
I guess I disagree somewhat with most of these ideas, but as the author of most of the existing code I suppose that's to be expected. I don't think converting between representations should be explicit; however the current behavior could certainly be improved. I think the second representation should be calculated as soon as it is needed by a function. My main thought is that a user of these functions should not ever have to think about that conversion. Perhaps you can explain what the advantage of the sort of HrepPolyhedron, VrepPolyhedron subclassing you mentioned would be? I have gone back and forth about changing the coordinate representation into something more sophisticated. At first I had coordinates as vectors, but found that annoying for reasons which I can't recall in detail. I like the simplicity of coordinates as lists of lists. For functions that could benefit from having things in matrix form, perhaps there could be a property like vertex_matrix that would store things in that way. Such a property could be created and stored only when it is actually needed to avoid redundancy. The matrix representation might make sense as the default if people started to write more sage-native polyhedral algorithms; my impression is that it will be easier to wrap other people's code for most purposes though (such as the volume computation with lrs). I have thought about sub-classing the 2- and 3-D cases. I have been working a bit on improving the projection methods for higher- dimensional polytopes, so that some rendering is possible. I'm not sure what the advantage of sub-classing is to the current behavior, where some functions just report their failure if they aren't defined in a particular dimension. I am interested in hearing other opinions about that. At some point it would be good to discuss unifying some of the other polytope code in sage as well, such as the LatticePolytope class and the graphics objects in platonic.py. Cheers, Marshall Hampton On Jan 28, 4:45 am, Sebastien Barthelemy <sebastien.barthel...@gmail.com> wrote: > Hello, > > I'm still trying to wrap cddlib by to python and, as it is beginning > to work, I wonder now how it should be integrated into sage. In > particular I think that polyhedra.py may benefit some refactoring. At > least, the topic is worth a discussion. > > About polyhedron representation > ~~~~~~~~~~~~~~~~~~~~~~~~ > > Any polyhedron admits two representations, let's call them Hrep and > Vrep. Currently, a single polyhedron class supports both > representations and calls cdd to convert from one to the other. This > conversion is done automatically as needed. This can be a problem > * in high dimensional spaces as the conversion is computationally intensive > * when using cdd with floats as the conversion leads to > approximations that can in turn lead to inconsistent representation, > * handling both representation together leads to lot of tricky boundary > cases. > > For these reasons > * I would prefer to have the conversion explicit rather than automatic > * we could split the current class into several ones, like > HrepPolyhedron, VrepPolyhedron (and maybe also DoubleRepPolyhedron) > inheriting from a common generic Polyhedron class. > > About vertices, inequalities, etc. datatype > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Currently, the Polyhedron class stores vertices and inequalites as a > python list of coordinates lists. > > This has two advantages: > * it has small dependency over other code > * it works for any coordinate datatype. In particular, cddlib can be > compiled to work with C double and rational coordinates, both can be > transparently stored in python lists. > > However, we could store them in matrix types and expect > * easier consistency checks > * fancy slicing > * better integration in sage > * faster code > > Currently, I only wrapped the part of cdd working on float > coordinates, and it outputs numpy arrays. Before continuing, I would > like to know if you prefer it to output lists (or sage matrices, > or...). > > Again, one would expect two distinct classes for polyhedron over RR or > QQ. However, as this aspect is orthogonal to the previous one, it > would lead to 2*2 (or 2*3) distinct classes. What do you think about > it? > > Dimension specific code > ~~~~~~~~~~~~~~~~~~ > > some methods in Polyhedron class only work in 2 or 3 dimension spaces > (mostly visualization tools) shouldn't we move them into a subclass? > > any thought? > > -- > Sébastien Barthélemy --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
