Thursday, September 10, 2009

geometric programming and trig functions

One of the most helpful ways to think about how to interact with dynamic geometry programs is to consider 'sketching' as programming (an unhelpful way to think of sketching is to think of it as drawing). This orientation is explained nicely by R. Nicholas Jackiw and William F. Finzer in Programming by Geometry:
Constructing a sketch in GSP is programming, in the straightforward sense of building a functional system which maps input to output. The unconstrained elements of the sketch... constitute the program's inputs or parameters. The relationships between parts of the sketch ... correspond to a program's production statements. In GSP's case, the semantics of the production language are governed by traditional Euclidean constructions.
The remarkable characteristic of GSP's system comes from the realization that a program's structure -- i.e. its "source code" -- and its output are isomorphic. When the student completes the specification, or coding, of the centroid construction in the above example, he or she has at the same time located a specific centroid. By manipulating the vertices of the triangle (the program's inputs), the student generates further output. Significantly, these manipulations are performed in the same domain, that of planar geometric objects, as the act of constructing the initial sketch.
Playing with hypocycloid constructions recently reminded me how nicely Sketchpad explorations help make the connection between circular motion and trig functions. For example, the sketches here include one that was inspired by a simple harmonic motion demo, and one that explores lissajous figures.

A nice overview that includes some similar sketches is given in a talk, Trig Comes Alive, by Scott Steketee from last year's NCTM annual conference.