In an earlier post, I reflected on the relationship between mathematics, language, and computer programming. One detail of that has been on my mind quite a bit lately, as I’ve been teaching geometry. While early computer programming was heavily reliant on a strong knowledge of mathematics, particularly algebra, I think that programming has evolved to the point where an understanding of modern computer programming can be useful in improving understanding of certain basic mathematics, particularly geometry.
I’ve been considering how an Object-Oriented Programmer would approach geometry. Geometry is full of objects, and full of property inheritance. For instance, let’s start with polygons. How might OOP tackle polygons?
Some exploration…
The Polygon class has several attributes: SideCount, SideMeasure[SideCount], AngleMeasure[SideCount], and InitialOrientation. SideCount is of type Integer (by definition, it’s greater than two). SideMeasure[] is an ordered array of type Real (by definition, it’s positive). AngleMeasure[] is an ordered array of type Aperture, where Aperture is a real number in the range 0 < Aperture < 2π (if any element of AngleMeasure[] equals π, then the polygon is degenerate).
The InitialOrientation class has several attributes: Point, an ordered pair of real numbers; Rotation, an Aperture representing the degree of rotation from the x-axis; and Flip, a Boolean indicating whether to interpret AngleMeasure[] clockwise (Flip == True) or counterclockwise (Flip == False).
If all AngleMeasure[] are in the range 0 < Aperture < π, then the Polygon is convex; otherwise, it’s concave. Whether it’s simple or complex (self-intersecting) requires a bit more math.
If all AngleMeasure[] are equal, the Polygon is Equiangular. If all SideMeasure[] are equal, the Polygon is Equilateral. If the Polygon is both Equiangular and Equilateral, then it’s Regular.
If two instances of Polygon are identical except for InitialOrientation, they’re congruent. If two instances of Polygon are identical, they’re equal.
Note that the final element of SideMeasure[] and AngleMeasure[] can always be uniquely calculated. We could even leave out one more element of either SideMeasure[] or AngleMeasure[] (but not both). For instance, the definition of a triangle only requires two angles and a side, or two sides and the angle between them. However, because the definitions of Equiangular and Equilateral require knowing these values, it makes sense to store them with the instance rather than calculating them on the fly each time.
Triangle and Quadrilateral both inherit Polygon (as do Pentagon, Hexagon, and so on), with the restriction that SideCount = 3 and SideCount = 4, respectively.
For triangles: If any two elements of SideMeasure[] are equal, then Triangle is Isosceles; otherwise, it’s Scalene. If any element of AngleMeasure[] is greater than π/2, then Triangle is Obtuse; otherwise, if any element is equal to π/2, then Triangle is Right; otherwise, Triangle is Acute.
For quadrilaterals: Rectangle is a Quadrilateral that is Equiangular. Rhombus is a Quadrilateral that is Equilateral. Square is a Quadrilateral that is Regular, so Square inherits both Rectangle and Rhombus. Rhombus is a Quadrilateral where either AngleMeasure[0] + AngleMeasure[1] == π or AngleMeasure[1] + AngleMeasure[2] == π, but not both. We could also define Rhombus as a case where AngleMeasure[1] + AngleMeasure[2] == π and AngleMeasure[0] + AngleMeasure[1] != π, but that would restrict the option of InitialOrientation. And so on.
… and then, reflection
So long as we don’t have computer programming as a prerequisite for high school geometry, I’m not advocating teaching geometry this way. However, I do think that laying it out in this way has helped me organize some of my own thoughts on geometry, and might help others as well.
One difference I’ve noticed between conventions in mathematics and computer programming is that the former grew up in spurts over centuries, and so there are lots of gaps and inconsistencies. Why, for instance, do we not have a symbol for two supplementary angles, when “supplementary” is such a key concept? Why must we use single letters for variables?
Computer programming, in contrast, has emerged out of an odd hybrid of specific language constraints (generally devised by small groups of people) and democratically derived “best practices”, in a much shorter time span. Computer programming best practices are still actively evolving, while the bulk of mathematical conventions have fossilized to the point that suggestions of change are heresy.
I think that computer programming conventions have benefited from this approach. I think that it’s time for us to seriously re-examine the gaps and inconsistencies in mathematical convention and to fix what needs to be fixed.
In this specific case, consider how polygons are typically taught. In Larson’s Geometry (2012 edition), “equilateral” and “equiangular” appear in this passage on page 43: “In an equilateral polygon, all sides are congruent. In an equiangular polygon, all angles in the interior of the polygon are congruent. A regular polygon is a convex polygon that is both equilateral and equiangular.”* There are some exercises on this notion, and then the book moves on.
On p. 207, students are told about equilateral and equiangular triangles. There’s no reminder in the text that these words applied to polygons 160+ pages previous. There’s no overt comment on p. 207 that equilateral triangles are always equiangular, and vice versa.
On p. 527, students are given definitions of squares, rectangles, and rhombi. Here they are: “A rhombus is a parallelogram with four congruent sides. A rectangle is a parallelogram with four right angles. A square is a parallelogram with four congruent sides and four right angles.” To my quick scan, the word “equilateral” only appears in section 8.4 in the exercises, and the word “equiangular” not at all.
One benefit of an Object-based thought process is that it allows for a cleaner organization of concepts. I’ve seen this approach taken within discussions of triangles and quadrilaterals, for instance, but extending it beyond it is rare and scattershot. Again referring to Larson’s Geometry, p. 528 has an Euler diagram (mislabeled, of course, as a Venn diagram) of the types of parallelograms. But where did “equilateral” and “equiangular”, terms whose distinction is far more important for quadrilaterals than for triangles, go? Why not more deeply teach that “equilateral” and “equiangular” apply to polygons, not specifically to triangles? That is, that triangles are not specifically equilateral, but rather that they can “inherit” the attribute of “equilateral” by virtue of being polygons?
* Note: Wikipedia and others allow for complex regular polygons, while MathWorld notes that there’s disagreement on whether self-intersecting objects are polygons. My Polygon class above currently allows for self-intersecting polygons.