So I finished the adventures in open source class at the police station. According to the academy, student reviews were quite positive. My co-teacher is moving out of state, so this particular chemistry is unlikely to be repeated, but the course content persists in various electronic formats (including Docbook SGML) and I hope will be built upon, by myself, the other teacher, or the academy (which has privileged access at this point).

This wasn't technically a math course, although mathematics was more than superficially present, and touched upon in several contexts.

For example, when discussing the transition from IPv4 to IPv6, in which internet addresses get lengthened from the current 32 bits to 128 bits, we found it most handy to be able to shell into Python and take advantage of the native long integer (precision integer) routines. 2**32 returns 4294967296L, and 2**128 returns 340282366920938463463374607431768211456L (the L at the end means "long" -- indicates we've switched types). Clearly the latter is a *much* bigger number. My coteacher expressed it in terms of IP addresses per square meter of the earth's surface, or something like that -- quite dense.

To take another example, we showed them how to hexdump a text file (or a binary for that matter). This gives entre to the all important ASCII encoding scheme, wherein Latin keyboard characters have their 7 or 8 bit binary representations, encoded in hex (base 16). And again, just as with the transition from IPv4 to IPv6, we're in the midst of a transition to a broader base. Instead of encoding with 0-255 (decimal, 8-bit, extended ASCII), we're moving to unicode. Instead of a mapping based on 2**7 or 2**8, we're moving to a map based on as many bits as needed, not just 16 (e.g. see UTF-8).

However, beyond this base-2 and base-16 stuff, mostly linked to mappings and/or permutations, we had a lot about coordinate geometry.

The starting point was this library of polyhedra stored in a particular text format at www.netlib.org/polyhedra/. These polys list vertices at the end, in a section marked :vertices, followed by a row giving some information about how many to expect. Earlier in the file, a section marked :solid,, if it exists, diagrams, using integers, how these vertices connect up. In other words, if the vertices are labeled 0-5, then a row in :solid would indicate a face, starting with the number of sides, followed by vertex-labeling integers.

So a core challenge of this course was to focus on the data structures and methods needed to read such files and extract just the relevant information. I had this coded before the class even started, so the presentation would mostly exercise reading muscles, not writing muscles. Just as recognition is easier than recall, when it comes to language learning, so eyeballing and parsing already-written source code is easier than writing it from scratch, and a good way to develop the skills (strong readers become strong writers).

The output of our polyhedron-reading code was more text, but in another format. The goal was to write a file in the scene description language understood by POV-ray, the Persistence of Vision Ray Tracer found at www.povray.org. To this end, I presented students with a minimal API: points (of measurable radius -- so spheres really), edges (cylinders) and faces (polygons) would be our stock in trade. To sketch a polyhedron in words, we needed only to specify the xyz coordinates of all the points, edges and faces, using the syntax expected by POV-ray.

The focus in this initial challenge was the topic of data structures. This is where I think ordinary K-12 mathematics might be usefully enchanced. Instead of focusing rather exclusively on sets, an SMSG holdover, and then only barely holding on to the associated concepts and notation, we broaden the view to take in lists and dictionaries. Lists stand for structures accessed by integer indices. Arrays or higher dimensional structures, accessed through more indices, all fall under this "list" heading. Dictionaries stand for associatively accessed data, i.e. some arbitrary but fixed key is paired with each value, and values are then retrieved not by integer index, but by key (possibly an integer, possibly a string -- anything immutable). Sets come across as a subtype of dictionary: all keys (keys must be unique) and no values.

So, for example, vertices might usefully be stored as a map (in a dictionary), mapping consective integers to xyz coordinate triples. Why not a list? A list would work in similar circumstances, but in these netlib polyhedra, the first vertices listed often pair with a :net section, all about drawing the polyhedron as a planar net, something one could fold along the creases to form the polyhedron. Given our focus on the :solid section, it behooves us to throw away many of the vertices, and yet to keep the original integer addresses. The map structure accomplishes this. So what if our lowest vertex address is 5? vertex[5] will be the xyz triple we need.

Edges might be most logically stored as a list of pairs, e.g. [(5,6),(6,7),(7,5)...], where the square brackets denote "list" and the curved parentheses denote "tuple" (similar to a list, but with immutable elements). But wait! Doesn't all this edge information derive from the faces? If my face is (5,6,7) with 5 connecting to 6, 6 to 7 and 7 back to 5, then can't I extract all the necessary edge information from the face information? Indeed. And this becomes another programming challenge.

Note: Don't get the wrong idea about this class. All this data structures and polyhedra stuff was a mere subset of the Python programming component. We did a whole lot more than just this, including playing with Pyblosxom, the Python software behind this blog, GrainOfSand

(to be continued)