Six Ways Coding Teaches Math

Last week I attended the Computer-Based Mathematics Education Summit in New York City, run by Wolfram Research and hosted at UNICEF headquarters.

The motivation behind the summit is explained by Conrad Wolfram in this TED talk.  His idea is that mathematical modeling almost always involves these steps:

1. Posing the right question.
2. Taking a real world problem and expressing it in a mathematical formulation.
3. Computation.
4. Mapping the math formulation back to the real world.

Wolfram points out that most math classes spend all of their time on step 3, and no time on steps 1, 2, and 4.  But step 3 is exactly what computers are good at, and what humans are bad at.  And furthermore, steps 1, 2, and 4 are important, and hard, and can only be done by humans (at least for now).

So he claims, and I agree, that we should be spending 80% of the time in math classes on steps 1, 2, and 4, and only 20% on computation, which should be done primarily using computers.

When I saw Wolfram's TED talk, I was struck by the similarity of his 4 steps to the framework we teach in Modeling and Simulation, a class developed at Olin College by John Geddes, Mark Somerville, and me.  We use this diagram to explain what we mean by modeling:

Our four steps are almost the same, but we use some different language: (1) The globe in the lower left is a physical system you are interested in.  You have to make modeling decisions to decide what aspects of the real world can be ignored and which are important to include in the model.  (2) The result, in the upper left, is a model, or several models, which you can analyze mathematically or simulate, which gets you to (3) the upper-right corner, a set of results, and finally (4) you have to compare your results with the real world.

The exclamation points represent the work the model does, which might be

• Prediction: What will this system do in the future?
• Explanation: Why does the system behave as it does (and in what regime might it behave differently)?
• Optimization: How can we design this system to behave better (for some definition of "better")?

In Modeling and Simulation, students use simulations more than mathematical analysis, so they can choose to study systems more interesting than what you see in freshman physics.  And we don't do the modeling for them.  They have to make, and justify, decisions about what should be in the model depending on what kind of work it is intended to do.

Leaving aside whether we should call this activity math, or modeling, or something else, it's clear that Wolfram's framework and ours are getting at the same set of ideas.  So I was looking forward to the summit.

I proposed to present a talk called "Six Ways Coding Teaches Math," based on Modeling and Simulation, and also on classes I have developed for Data Science and Bayesian Statistics.  For reasons I'm not sure I understand, my proposal was not accepted initially, but on the second day of the conference, I got an email from one of the organizers asking if I could present later that day.

I put some slides together in about 30 minutes and did the presentation two hours later!  Here are the slides:

Special thanks to John Geddes, who also attended the CBM summit, and who helped me prepare the presentation and facilitate discussions.  And thanks to Mark Somerville, who answered a last minute email and sent the figure above, which is much prettier than my old version.

Here's an outline of what I talked about.

Six Ways Coding Teaches Math

My premise is that programming is a pedagogic wedge.  If students can write basic programs in any language, they can use that skill to learn almost anything, especially math.

This is also the premise of my book series, which uses Python code to explain statistics, complexity science, and (my current project) digital signal processing.

I presented six ways you can use coding to learn math topics:

1) Translation.

This is probably the most obvious of the six, but students can learn computational mechanisms and algorithms by translating them into code from English, or from math notation, or even from another programming language.  Any misunderstandings will be reflected in their code, so when they debug programs, they are also debugging their brains.

2) "Proof by example".

If you prove a result mathematically, you can check whether it is true by trying out some examples.  For example, in my statistics class, we test the Central Limit Theorem by adding up variates from different distributions.  Students get insight into why the CLT works, when it does.  And we also try examples where the CLT doesn't apply, like adding up Pareto variates.  I hope this exercise helps students remember not just the rule but also the exceptions.

3) Understanding math entities by API design.

Many mathematical entities are hard to explain because they are so abstract.  When you represent these entities as software objects, you define an application program interface (API) that specifies the operations the entities support, and how they interact with other entities.  Students can understand what these entities ARE by understanding what they DO.

An example from my statistics class is a library I provide that defines object to represent PMFs, CDFs, PDFs, etc.  The methods these object provide define, in some sense, what they are.

This pedagogic approach needed more explaining than the others, and one participant pointed out that it might require more than just basic programming skills.  I agreed, but I would also suggest that students benefit from using these APIs, even if they don't design them.

4) Option to go top down.

When students have programming skills, you don't have to present every topic bottom-up.  You can go top-down; that is, students can start using new tools before they understand how they work.

An example came up when I started working on a new textbook for Digital Signal Processing (DSP).  In DSP books, Chapter 1 is usually about complex arithmetic.  If you approach the topic mathematically, that's where you have to start.  Then it takes 9 chapters and 300 pages to get to the Fast Fourier Transform, which is the most important algorithm in DSP.

Approaching the topic computationally, we can use an implementation of FFT (readily available in any language) to start doing spectral analysis on the first day.  Students can download sound files, or record their own, and start looking at spectra and spectrograms right away.  Once they understand what spectral analysis is, they are motivated and better prepared to understand how it works.  And the exercises are infinitely more interesting.

5) Two bites at each apple.

Some people like math notation and appreciate how it expresses complex ideas concisely.  Other people find that the same ideas expressed in code are easier to read.  If you present ideas both ways, everyone gets two chances to understand.

Sometimes math notation and code look similar, but often they are very different.  An example that comes up in Think Bayes is a Bayesian update.  Here it is in math notation (from Wikipedia):




And here is the code:

class Suite(Pmf):
    """Map from hypothesis to probability."""

    def update(self, data):

        for hypo in self:
            like = self.likelihood(data, hypo)
            self[hypo] *= like

        self.normalize()

If you are a mathematician who doesn't program, you might prefer the first.  If you know Python, you probably find the second easier to read.  And if you are comfortable with both, you might find it enlightening to see the idea expressed in different ways.

6) Connect to the real world.

Finally, with computational tools, students can work on real world problems.  In my Data Science class, students aren't limited to data that comes in the right format, or toy examples from a book.  They can work with datasets from almost any source.

And according to Big Data Borat:

In Data Science, 80% of time spent prepare data, 20% of time spent complain about need for prepare data.

So students work with real data and interact with real clients.  Which reminds me: I am looking for external collaborators to work with students in my Data Science class, starting January 2014.

UPDATE: Here's an article by Michael Ernst about his class, which combines introductory Python programming and data processing: Teaching intro CS and programming by way of scientific data analysis


Audience participation

So that was my presentation.  Then I had a little fun.  I asked the participants to assemble into small groups, introduce themselves to their neighbors, and discuss these prompts:  Are there other categories in addition to the six I described?  Are the people in the audience doing similar things?  How do these ideas apply in secondary education, and primary?

After a day and a half of sitting in presentations with limited interaction, many of the participants seemed happy to talk and hear from other participants.  Although when you break our active learning methods on a naive audience, not everyone appreciates it!

Anyway, I sat in on a some excellent conversations, and then asked the groups to report out.  I wish I could summarize their comments, but I have to concentrate to understand and facilitate group discussion, and I usually don't remember it well afterward.

One concern that came up more than once is the challenge of building programming skills (which my premise takes for granted) in the first place.  There are, of course, two options.  You can require programming as a prerequisite or teach it on demand.  In the Olin curriculum, there are examples of both.

Modeling and Simulation does not require any programming background, and each year about half of the students have no programming experience at all.  While they are working on projects, they work on a series of exercises to develop the programming skills they need.  And they read "The Cat Book," also known as Physical Modeling in MATLAB.

For most of my other classes, Python programming is a prerequisite.  Most students meet the requirement by taking our introductory programming class, which uses my book, Think Python.  But some of them just read the book.

That's all for now from the CBM summit.  If you read this far, let me ask you the same questions I asked the summit participants:

1. Are there other categories in addition to the six I described?
2. Are you doing similar things?
3. How do these ideas apply in secondary education, and primary?

Please comment below or send me email.