Computational Problem Solving Workshop

Portrait of Euler, shamelessly lifted from Project Euler.

One of the things that we believe strongly is that there needs to be better use of computers in math education, in part because computers play such a huge role in how math is actually done these days.

To that end, I ran a one-day workshop on mathematical problem solving using Sage today. The idea is to run this workshop as a kind of seminar series next term, once we get back from South Africa, and today served nicely as a dress-rehearsal. The students who came today were all in first-years in computer science; it should be interesting to see how things play out with math students next term, who haven’t necessarily been exposed to the programming side of things as much.

Here’s how things went down:

  • We started with an introduction to the Sage notebook and some basic Sage syntax.  Really just got things open, showed how to get at functions and documentation, demonstrate variable assignment, if statements, for loops, and a couple other real basics.  The sort of absolute building blocks you need to start programming in a new language.  The dummy problem was writing a function which takes a number and writes whether it’s equal to 2 or not.  Someone, in their reporting string, wrote that the number is/is not even instead of is/is not 2.  This led to a quick introduction on how to do modular arithmetic in Sage, which proved quite useful later.
  • Then we collectively checked out Project Euler.  We worked out the first problem together (find the sum of all numbers less than a thousand which are divisible by 3 or 5.)  Then I showed a one-line solution using Sage’s nice list-building ability:
    sum([i for i in [1..1000] if (i%3==0 or i%5==0)])

    The one-line solution was probably a bit too much to give at this point, but I thought it was a nice way to reinforce the power of the programming language.  But I then explained that the long-way of writing things out was probably better for beginners, since it’s much much easier to track down bugs in longer-form code.

  • Then I sent the group on to try out the second problem: find the sum of all even Fibonacci numbers less than 4 million.  I gave about ten minutes for people to try it out.  There were a couple pretty sharp guys who started working out how to generate the Fibonacci numbers, but probably the most substantial progress was made by a group of three girls working together.
  • At about this point the power went out.  And the generator turned on, but the power wasn’t getting to us…. So we wrote up the code for a solution to the Fibonacci problem on the board, using suggestions from the class.  We also did some nice stuff ‘running’ the code and keeping a register of the variables as we went through our main ‘while’ loop.  This helped figure out where problems were in the code, of course, and I think was a useful exercise for the students.  All told, it probably wasn’t entirely terrible that the power died.

The main thing lost in the power outwage was the survey I’d put together to get a better idea of the student’s backgrounds.  I then hung around and answered questions for a bunch of students for an hour or so.

I think it was a pretty good trial run.  One thing I’ll definitely do next time is pair students off.  I think having four eyes on a particular screen will help cut down the syntax errors quite a bit; some students were fine at picking up the syntax, others were clearly really struggling.  Pairing off also better encourages group work when it comes time to work on problems.  Good times.