[Edu-sig] Pickling Polyhedra

[kirby urner]

OK, so this title is somewhat misleading, because pickling and
shelving is one of the things I've not yet gotten around to, vis-a-vis
Polyhedra.  But let me tell you about some of the other things I've
done (classic bait and switch, I realize).

First, what data structures to use?  Well, no need to reinvent the
wheel here.  Geometers discovered long ago that labeled vertices made
a lot of sense, which suggests a dictionary.  But we're not done. 
What vertices connect to what?  Just edges (pairs of connected
vertices) might seem like the answer but then figuring out the faces
turns out to be hard, relative to how easy it'd be if the faces were
simply a part of the data.

And that suggests a list of tuples perhaps, the list being Faces and
each tuple being a face.  Within the tuple, labels, keys in a
dictionary of saved Vertices.  And what about edges?  They derive from
Faces, by means of a simple algorithm (weeding out duplicates is part
of it -- the native Set type may prove useful).

So what about the *values* of our Vertexes dictionary?  [Vertexes: an
intentional respelling, per Synergetics -- I like the
'x-marks-a-rail-crossing' aesthetic].  I vote for vectors (lovely
alliteration).  Of course the Clifford Algebra people may have other
ideas, and I can't say I'd be against them.  But for now, simple XYZ
coordination is sufficient, or try our newfangled Quadrays, with
only-positive four-tuples (a member of the "simplicial coordinate
system" family -- "simplicial" from "simplex," our tetrahedron or
"minimum system" in synergetic geometry).

So that's the data structure:  a dictionary of vertex vectors,
gathered into face-tuples in a list.  There's good practice with all
three main collection types here, plus strings, if you use those to
label your vertices (you could also just use plain integers, a popular
choice among computational geometers).

So one design pattern would be this:  define your Polyhedron class to
"eat" your data structures.  Build in rotation, translation and
scaling.  Have the results of these operations be new polyhedra, i.e.
these are not "changes in place" even if the rotations are minor. 
Every change begets a new self.  Very Buddhist, very "be here now".

Then, make a Writer superclass as a paradigm consumer of these
Polyhedron objects (an icosahedron say, or rhombic triacontahedron of
120 T modules).  The polyhedra themselves are fairly innocent of i/o. 
At this superclass level, maybe there's a default data dump, a YAML or
XML generator.  But anything more elaborate and application specific,
such as a VRML, VPython, POV-Ray, EIG or LiveGraphics3D writer (and
I've written all of these in my day), should simply eat a Polyhedron
and scribble the file.  The Polyhedron class itself remains blissfully
ignorant of all these nitty gritty requirements.

>From a students point of view, how might all this work?  XML and file
i/o is probably going to come through other topical segments.  I'm a
big fan of using kml files ("camel files") out of Google Earth.  The
syntax of class construction will likewise already be familiar, as
will these basic Python data structures (dictionary, tuple and list).

The Vector concept might be new though.  We could start with that. 
Vector algebra is very graphical, plays well with geometry.  A
computer graphics savvy curriculum is going to need vectors. 
Implement these natively in pure Python.  Then get into the rotation
algorithms.  3x3 matrices should be sufficient (our newfangled
Quadrays come with 4x4s, thanks to Tom Ace) -- no need for homogenous
coordinates at this level.

To rotate is to hit every unique vector in the Vertexes dictionary,
and to spit back a new poly (now rotated).

My inclination is to focus on POV-Ray early, as this full featured ray
tracer offers hours of fun to those who would get lost in it.  A
Python polyhedron writer only takes advantage of a small subset of
POV-Ray's capabilities, but there's much more to explore "off camera".
 A goal is to unleash the artist in each student, to give them high
powered creativity tools.  Yes, mastery of mathematics is important,
but not at the expense of a well-developed sense of aesthetics. 
"Ethics = aesthetics" wrote Ludwig Wittgenstein, in his Tractatus
Logico-Philosophicus.  Our Python-based mathematics aims for some
Athenian style panache, not just for Spartan style bare bones
efficiency.

Where to go after POV-Ray I'm not so sure.  I'm not sure it matters. 
Depends on the curriculum, the teacher, the student.  Plus I'm
expecting the IronPython branch to open new territory, hitherto
unexplored.  VPython is certainly fun, per Arthur's PyGeo, my
Hypertoons, and any number of art-science projects that others may
brainstorm.  I'm looking forward to witnessing a lot of creativity in
these areas, having helped craft a launching pad or starting gate,
with plenty of help from others (Pythonistas, Pyconistos -- some in
full Monty).

Anyway, now that we've got Python and Polyhedra in the picture, I'm
thinking mathematics learning will be a lot more rewarding and fun. 
Let the good times roll.

Exercise:

Relate the above design pattern proposal to the model-view-controller
architecture.  Explain how the above might be consistent and/or
inconsistent with MVC concepts.

====

K. Urner
4D Studios
PDX USA
2006.3.21