Previous
Next

Programming, lectures, and the inverted classroom

March 23, 2010, 1:25 pm

Punch card from a typical Fortran program.
Image via Wikipedia

We started programming in the MATLAB course a couple of weeks ago. It’s been… interesting. Keep in mind that 75% of the students in the class have never written a program of any sort before; half the class rates themselves below a 6 out of 10 in “comfort level” in using computers at all. As with everything else in this course, the audience is everything.

I started this three-week unit last week with a minilecture on FOR loops. But wait, you say: I thought you were using an inverted classroom model for the MATLAB course, where students are assigned reading and viewing tasks outside of class, accompanied by homework assignments designed to help them extract the relevant information and then do simple applications of what they’ve learned. Well, yes, that’s been the plan, and the practice up until now.

But I decided to go with a minilecture/activity model for the programming unit for two reasons. One, as has been the case much of the time when putting this class together, I wasn’t finding any materials out there to give out to students on the absolute basics of MATLAB programming — by which I mean the concept of the function M-file and looping structures (we’re getting to branching structures later) — that is suitable for a total-novice audience. The Mathworks, Inc. tutorials, usually well-suited for this kind of thing, were just a little too advanced. And there just wasn’t much else out there on this subject that I’ve found that was free, online, and well-suited for this kind of thing. If you think that smells like a screencasting opportunity waiting to happen, you might be on the right track.

Secondly, the students have been struggling with this inverted classroom model even when the materials I give them are good and the subject (like curve fitting) is both familiar and pretty basic. The struggles have been mainly cultural and psychological, not intellectual. The students are plenty smart enough to pick up the basics on their own. But we’ve run into some linear combination of these issues:

  • Not adopting an appropriate timetable for learning the material outside the classroom. That timetable is: get to work early on the stuff, spend small chunks of time on it, and make those chunks frequent. The ideal schedule probably comes out to: no more than 30-45 minutes at a sitting, done over the course of 5-6 days. That jives with the “2 hours outside of class for every hour inside of class” conversion factor that usually works for college. Instead, the average start time on the outside work has been less than 24 hours before the labs.
  • An expectation that after watching the videos or doing the reading, we are now ready to write workable code. There has not been widespread recognition that programming, or just working with a computer system in general, is all about getting your hands dirty with stuff that is not assigned before there is a chance of doing correctly the things that are assigned. There is a certain amount of time between being exposed to information and being able to do something right with it, and that time has to be spent doing things wrong with it. The misunderstanding, common to this demographic, is that information = expertise. Get exposed to the information enough, and you’ll be good at whatever that info was about.
  • A simple psychological block against the idea that basic acquisition of concepts can take place in the absence of an expert.

I asked students in a questionnaire what changes to the class would help them learn MATLAB better. Overwhelmingly (75%) the students said that a lecture before the lab activities would be helpful, even though this would mean drastically reduced time on the labs in class and therefore more time spent outside of class, which is something they (understandably) don’t want. When I asked a couple of students what they expected to get from a lecture that they can’t get through online materials, use of the class discussion board, office hours, or conversations with their lab partners, the answer was: We’d just feel better about things if you’d lecture.

So, as I said, I started the first programming class with a minilecture. I walked students through the creation of a function called sin_period:

[sourcecode language="matlab"]
function period = sin_period(p)
period = 2*pi/p;
x = linspace(-2*pi, 2*pi);
plot(x, sin(p*x))
[/sourcecode]

So this is an unsophisticated example of how you can write a MATLAB function that does a couple of pretty different things at once. It calculates the period of \(y = \sin(px)\) where the parameter \(p\) is provided by the user, and then it generates a plot of this function. Lab activity #1 given to the students: Modify this function so that the plot contains exactly two periods of \(y=\sin(px)\) and it puts a plot of \(y=\sin(x)\) on the same plot, using a dashed red line, for reference. (I really sold this to the education majors, who make up half the class, as an example of where a MATLAB function could be a useful classroom demo tool for a trigonometry or precalculus class.)

The second demo in the minilecture was using a basic FOR loop:

[sourcecode language="matlab"]
for i=1:10
disp(['The square of ', num2str(i), ' is ', num2str(i^2)])
end
[/sourcecode]

This was actually given out in homework during the week with the instructions to change stuff in this loop and see what happens. What is the disp command doing? What is that num2str command and why do we need it? What happens if we leave off the square brackets inside disp, and why do we get the error message we get? And above all, what does this code actually do? What would you change to get it to print out the squares of the first 20 positive integers? And so on.

I wanted this to be not so much a minilecture as a discussion among students of what they did, what they encountered, and what they learned during their code-tweaking. But it ended up being nothing but me lecturing. I’m not sure what happened. Certainly I didn’t insist on students sharing what they discovered; maybe I was getting nervous about taking up too much more lab time.

After this was over, I gave Lab activity #2: Write a function M-file called vector_diff that accepts a vector “x” as input and produces a vector “d” as output, whose entries are the differences in consecutive entries of “x”. For example, vector_diff([1 3 0 8]) should return [2 -3 8]. Of course the diff function in MATLAB already does this, and some students figured that out, but the point was to recreate that functionality from scratch to learn how a FOR loop works.

So, you ask, how did that lab turn out?

It was all over the map in terms of quality. With the sin_period activity, about half the students got it exactly right. The other half almost uniformly added in the plot of \(\sin(x)\) with the correct color and linestyle but were unable to get the function to adjust the x-range so that two periods of \(\sin(px)\) show up. In other words, they were able to add in the routine stuff (just a plot command) but not able to transfer the idea of local variables within functions to use the period (which we’d already calculated) to set the x values. (All you have to do is replace x = linspace(-2*pi,2*pi) with x = linspace(-period, period).)

The FOR loop had a lot more variation. Some groups got it almost exactly right (biggest obstacle: not knowing how to add new entries to a vector). Some groups wrote code that appeared to be trying to use the right ideas, but the syntax was way off, for example using the counter variable “i” as if it were a vector (for example, using i(1):i(n) as the range on the counter). Some groups turned in nothing at all; although it turned out later that those groups had something done, but because it wasn’t exactly correct they decided to turn in nothing.

This is not a total loss, and this week (which I’ll report on later) I think we improved a lot through some more basic discussion of how to program, in general. But I take several lessons away from the results of the week 1 lab, with its much-requested lecture component:

  • Lectures are only helpful to the extent that they impel students to act on what they are hearing. If you want a lecture just because you’d like an expert to assuage your misgivings about a subject — you want a lecture merely to feel better and more centered about what you’re learning — then the lecture is going to accomplish nothing other than providing a false sense of security to the students. Is this helping the student? No.
  • Students who are still less than one year out of high school, where largely the opposite of what we’re doing in this class is the norm, have no idea that the first point is the case. For most students in this concrete mode of thinking, teaching = lecture = learning. This doesn’t mean they aren’t smart or capable of becoming self-supporting learners, which is sort of an overall goal of my teaching in any class. It does mean that they have to be exposed to activities that enable or require self-sufficiency, early and often. Or else they will be totally unable to function after they graduate.
  • Therefore I’m more convinced than ever that the inverted classroom model for this class really is the right way to go. Give students “lectures” outside of the class time; give them time to think, questions to answer, simple tasks to perform that are based on what they read and watch. If they do it, this will generate the right questions which they can then ask (themselves, their lab partners, or me). Then they have an entire class meeting in which to do some more complicated task.
  • But this only works to the extent that students adopt the short/frequent/early schedule for working on the material. If students continue to operate on the assumption that 300 minutes applied in a single 2.5-hour block late on Sunday night is the same as 300 minutes applied in five 60-minute blocks across multiple days of the week, then of course they’ll choose what appears like the lowest-footprint model and go with the single big block. But this is a flawed assumption, especially in an activity which most students self-identify as being something with which they are totally unfamiliar and largely not all that comfortable.
  • This means I have to do a better job of getting students to realize this. I don’t want to start FORCING students to work this way — for example, by having teams submit journal entries or blog posts or something every couple of days. I’d rather get them to see that learning a computer tool is much more fun when you give yourself time to play, time to make and correct mistakes — time to get used to the kinds of expert behaviors that computer people employ. Incentivize rather than require.

The story continues.

Reblog this post [with Zemanta]
This entry was posted in Critical thinking, Education, MATLAB, Teaching, Technology, Uncategorized and tagged , , , , , , , , , . Bookmark the permalink.