I discovered Paul Lockhart’s A Mathematician’s Lament via Isabel Lugo’s post at God Plays Dice. That post also introduced me to Keith Devlin’s monthly column Devlin’s Angle; the latest installment responds to feedback that he and Lockhart have received since the publication of the March column in which the Lament was published.
One of Devlin’s reactions to the Lament is that it doesn’t serve the needs of most people who are learning mathematics. He writes that
[Mathematics] is one of the most influential and successful cognitive technologies the world has ever seen. Tens of thousands of professionals the world over use mathematics every day, in science, engineering, business, commerce, and so on. They are good at it, but their main interest is in its use, not its internal workings. For them, mathematics is a tool. … Industry needs few employees who understand what a derivative or an integral are, but it needs many people who can solve a differential equation.
The question of use—of mathematics as a tool—is a recurring theme in Devlin’s column. The June 2007 installment, for example, started off this way:
One problem with teaching mathematics in the K-12 system – and I see it as a major difficulty – is that there is virtually nothing the pupils learn that has a non-trivial application in today’s world. The most a teacher can tell a student who enquires, entirely reasonably, “How is this useful?” is that almost all mathematics finds uses, in many cases important ones, and that what they learn in school leads on to mathematics that definitely is used.
Things change dramatically around the sophomore university level, when almost everything a student learns has significant applications.
I am not arguing that utility is the only or even the primary reason for teaching math. But the question of utility is a valid one that deserves an answer, and there really isn’t a good one. For many school pupils, and often their parents, the lack of a good answer is enough to persuade them to give up on math and focus their efforts elsewhere.
Utility, unfortunately, is particularly tricky to evaluate. It almost always depends on the context in which it is applied. For example, floating point computations on computers generally have a high degree of utility. They are our best approximation to the real numbers; they are used in nearly all numerical approximation algorithms. However, their utility drops significantly when they’re used to represent money.
There’s another example that I want to talk about briefly. Let’s consider Isabel’s comment on proofs in high school geometry:
[Lockhart’s] most annoyed at the fact that when school mathematics does teach the idea of “proof” — which for traditional reasons is done in geometry classes — the proofs that students produce are so different from real proofs as to be unrecognizable. For those of you who don’t know, students in American schools are subjected to something called a “two-column proof” in which a sequence of statements is made in one column, and justifications for those statements is made in an adjacent column. I can imagine how this would be useful for very carefully checking if a proof is correct. But anybody who was actually reading such a proof in an attempt to learn something would probably attempt to translate it back to natural language first! I suspect that the real reason such “proofs” are so common in such courses is because they’re much easier to grade than a proof actually written out in sentences and paragraphs.
This type of proof introduces students to the important concept of traceability, which has a very high degree of utility in software development. Software systems are frequently large, complex, and expensive to build. (Software projects also fail, much more frequently than most people outside the software industry realize.) The typical software development project needs to meet specific goals, which are the requirements to be met by the software system when the project is completed. As the software is designed, there are two questions that need to be answered:
- Are all the requirements being met?
- Why are we building each of these components? What requirement do they help us satisfy?
The two-column proof in high-school geometry traces the asserted geometric property to a supporting justification for that assertion. This is precisely the idea of traceability that is needed to answer these fundamental questions in software development. Once the design for the software system is completed, we need to consider each requirement as an assertion that the software will have a particular property. Elements of the design must be offered as support justifying that assertion. Likewise, one check to help ensure that the design hasn’t introduced a mass of unnecessary work, the components can be treated as assertions to be justified by the requirements.
From the standpoint of understanding a proof in geometry, it may be entirely reasonable to “translate” the proof into paragraphs. An itemized list of requirements, however, may consist of several hundred individual items; these may be supported by a design that specifies the construction of a couple thousand components of various types. When these were written out in sentences and paragraphs, it is simply too easy to miss important aspects of the requirements and the design, which often incorporate complex relationships that cannot be captured in a linear “sentence and paragraph” format.
Now, consider the utility of a two-column proof when we have multiple objectives: an understanding of the geometric argument and an understanding of traceability. The two column proof may have relatively low utility in terms of mathematical understanding, but relatively high utility in terms of understanding complex systems.
There is one more potential issue with this utilitarian view of mathematics. If we return to Devlin’s column, we find that his January and February installments from this year actually suggest that the United States should be outsourcing the “routine mathematics”—presumably this refers to things like solving differential equations, since these are situations where we use mathematics as a non-trivial tool. (The trivial applications can generally be handed off to handheld calculators, spreadsheets, or computer math programs; there is no reason to outsource those tasks that are commonly handled by a microchip.)
This line of reasoning suggests some rather serious issues. If the mathematics taught in the K-12 environment has no real applications (Devlin’s June 2007 contention), and we outsource the routine mathematics that arises when we consider mathematics as a tool to achieve some other goal (his May 2008 suggestion), the argument that learning mathematics has any utility becomes particularly problematic.
Copyright © 2008 Michael L. McCliment.