Thanks very much for that feedback! I am totally swamped right now teaching at AIMS (http:// www.aims.ac.za/), since its like a semester course in 3 weeks, but when I am done I am eager to start in on these issues. Right now I just want to keep up with what Sebastien is doing.
-Marshall On Jan 28, 9:07 pm, Carl Witty <[email protected]> wrote: > On Jan 28, 12:44 am, mhampton <[email protected]> wrote: > > > Hi Sébastien, > > > Let me first say I am glad you are working on and thinking about this. > > Me too. > > ... > > > 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 can't get too excited about choosing the internal data structures. > As long as they aren't exposed inappropriately, it shouldn't be hard > to change them later. > > As an example of inappropriate exposure: the following is unfortunate > (and probably rises to the level of "buggy"); especially since > the .vertices() docstring doesn't mention the dangers. > > sage: square = Polyhedron(vertices = [[1, 1], [1, -1], [-1, 1], [-1, > -1]]) > sage: verts = square.vertices() > sage: verts.append((pi, e)) > sage: verts[0].append("Hi mom") > sage: square.vertices() > [[1, 1, 'Hi mom'], [1, -1], [-1, 1], [-1, -1], (pi, e)] > > > 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. > > I don't think it makes much difference. One difference is that > subclassing can give better tab-completion behavior, where tab- > completion only shows the methods that actually work. > > > 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 > > Let me explain some of my desires for a polyhedron class. The most > drastic is that I would like to support non-convex polyhedra. For > instance, I would like to be able to represent a great stellated > dodecahedron, with a representation that "knows" that it has 20 > vertices and 12 faces (each of which is a pentagram). (So a non- > convex polyhedron can't just be a union of convex polyhedra.) > > This is so different from the existing Polyhedron class that it may > not be useful (or possible) to merge them. > > Second, I would like to support vertices with algebraic coordinates. > Taking again the great stellated dodecahedron, I don't think you can > embed it in R^3 with all coordinates rational; so to represent a > (mathematically perfect) great stellated dodecahedron, you need > algebraic coordinates. > > At least the first steps of "supporting algebraic coordinates" the way > I mean are not very difficult. Basically, just allow arbitrary Sage > types in the vertex lists (preferably ensuring that they are uniform, > though). Then, anywhere you're about to call an external library or > program, raise an error instead, if your coordinate type isn't > something you know how to handle; this gives you a highly crippled > Polyhedron class that kind-of supports algebraic coordinates. Then, > over time, people can go in and add generic Sage code to replace the > errors. > > Carl --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
