Analyze, hack, create

One of these days I’ll get back to blogging about the mathematics courses I teach, which make up the vast majority of my work, but the MATLAB course continues to be the place where I am working the hardest, struggling the most, learning the biggest lessons about teaching, and finally having the greatest sense of reward. This week was particularly rewarding because I think I finally figured out a winning formula for teaching a large portion of this stuff.

This was the last in a three-week series on introduction to programming. We had worked with FOR loops already. I had planned to look at WHILE loops in the same week as FOR loops, then have the students play around with branching structures in week 2, then have them apply it to writing programs to do numerical integration week 3 for use in their Calculus II class in which most of the class is currently enrolled. But the FOR loop stuff went very roughly. So I moved the numerical integration stuff up a week and saved the entire remainder of looping and branching structures — WHILE loops, the IF-ELSEIF-ELSE structure, and SWITCH — for week 3.

I approached it like this.

The majority of their homework consisted of watching three videos: one on general programming in MATLAB, another on MATLAB loop structures in general, and a third on IF and SWITCH statements. That’s about 20 minutes of straight viewing; I told the students to budget an hour for these, since they’ll want to pause and rewind and work alongside the videos. Then, the majority of their homework was this M-file:

%% Script M-file for April 5 Prep/HW for CMP 150.
%
% For each block of code below, write a clear, English paragraph that
% explains what the code does. You can play with each block of code by
% removing the comment symbols and running this file. (You can "uncomment"
% lines by deleting the percent symbol or by highlighting the code you want
% and selecting Text > Uncomment from the menu above.)

%% Code example 1

 x = input('Please enter in a number less than 100: ');
 while x < 100
     disp(x)
     x = 2*x - 1;
 end

%% Code example 2

 x = input('Please enter in a number: ');
 if x>=0
     y = sqrt(x)
 else
     y = exp(x) - 1
 end

%% Code example 3

 value = input('Please enter in a whole number between 1 and 20: ');
 switch value
     case {2, 3, 5, 7, 11, 13, 17, 19}
        disp('Your input is a prime number.')
     case {1, 4, 6, 8, 9, 10, 12, 14, 15, 16, 18, 20}
         disp('Your input is a composite number.')
     otherwise
         disp('I do not think you entered in a whole number between 1 and 20.')
 end

In other words: Here’s a bunch of code. Write up a plain-English description of what everything is doing. That was their homework. (Here’s the full assignment.)

Then in class, we played a game. For each code sample, I asked, “What if I entered [fill in the blank] to this bit of code?” For example, for code sample #1, what would happen if I entered in 100? One student immediately said, “Nothing”. Another said “It would give you a ‘0’ because that’s what ‘100 < 100’ returns as in MATLAB.” Then I had them close their eyes. “How many say, ‘Nothing’?” Count the hands that go up. “How many say ‘0’?” Count those hands. Put the tally on the board. The result: 7 for “nothing”, 6 for “zero”. Instant discussion fodder.

(By the way, this would have been a perfect place for clickers. I’m working on that.)

Next I asked, “What would happen in code sample 1 if I put in a negative number?” One guy said: “I know! I did that, and the thing kept running and never stopped, and I had to unplug my computer!” So I showed them all Control-C; then asked, “Why did that [the failure of the program to stop] happen?” In no time at all — a high-order discussion about an important related topic to looping structures (avoiding infinite loops) that I had not even planned to bring up.

We played that game for 20 more minutes. Students were into it. They were coming up with their own cases. We tried entering in ‘Hi mom’ to code sample #1 and it actually gave something back. It was mysterious and entertaining and nerdy. They discovered that testing out extreme cases is not only important for understanding your code, it’s fun. And it was a lot better than lecturing.

The best thing is, when I got them finally into their lab problems, they were asking better questions. “I think I can do this program with a SWITCH statement, but could I make it better with an IF statement?” And: “I’ve got all the cases listed out here in my SWITCH statement, but I wonder if I could just use a vector or LINSPACE to list them out instead.”

So that’s going to be my approach from here on:

1. Analyze: Look at someone else’s code and write out a complete, plain-English description of what every part of it is doing.
2. Hack: Take the same code and modify it, tweak it, rewrite it, throw extreme cases at it. This is the bridge between reading code and writing code.
3. Create: Write some code to do something new — now that you’ve learned the language from someone else’s use of it.

For all I know I could be totally reinventing 40-50 years of established best practices in computer science pedagogy. But it’s pretty exciting nonetheless.

Advertisement