On Jan 28, 12:44 am, mhampton <hampto...@gmail.com> 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 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
-~----------~----~----~----~------~----~------~--~---
