# Gas station without pumps

## 2013 February 3

### Conjecture about gnuplot difficulties for students

Filed under: Circuits course — gasstationwithoutpumps @ 23:26
Tags: , , , , ,

A number of the students in my circuits class have been having difficulty with gnuplot, but did not turn in their gnuplot scripts with their lab reports, so I could not examine the scripts to look for misunderstandings.

Debugging class lessons is much harder than debugging programs, because the computers are much more deterministic, and I can usually add extra print statements to narrow down where things are going wrong. I can’t seem to get the students who are having difficulty to show me what they can and can’t do, which makes figuring out what to explain to them difficult.  There are dozens of things that they might be hung up on, and shotgun techniques where I tried to cover lots of them have not been very successful.

I have a conjecture about what is causing the students greater difficulty than I expected: scope of variables.  These students have had lots of math classes, but few or no programming classes, and their math skills seem to be mainly formal manipulation.  They have probably not been exposed much to the notion that the same variable may have different values in different contexts, or that variables need to be given different names if they are to be used in the same context.  Math classes either always use the same variable (all derivatives with respect to x, for example) or pick new variables for each equation. It is rare for math classes to use the same function repeatedly with different parameters, and plot that function several times on the same graph.  It shouldn’t be rare, but it seems to be.

I was taking scope of variables for granted in my presentations of gnuplot, since all my previous students had already been well exposed to the idea. (Well, maybe not the 5th graders I taught Scratch to, but Scratch has a simple scope notion, tying variables to sprites that are the visible objects the students are manipulating, so the problem is finessed.)

The scope rules for gnuplot are actually fairly subtle, as there are expressions that are only applicable in connection with a particular data file (like the \$1 and \$2 column variables), there are variables whose scope is just the “plot” or “fit” statement (like “x”), there are variables whose scope is a function definition (the parameters of the function), and there are variables whose scope is global (the parameters being fit in a “fit” statement, for example).  I never explained these scope rules to the students, and the tutorials on gnuplot don’t do so either, since they are all written by programmers for whom the scope of variables is “obvious” and doesn’t need much explanation.

How will I test whether this is indeed the sticking point for the students who are having trouble?  What exercises or explanations can I give them to get them to understand scope well enough?  The course is not a programming course, so the usual approaches of programming courses are probably not appropriate. This  pedagogical problem requires more thought—suggestions are welcome.

1. I forget, did you do a hands-on tutorial with them? I teach a lot with Mathematica, and the rare successful times I’ve done it, it’s always involved a (tedious) hands-on session. It seems showing students completed code that’s pretty easy to copy isn’t the same as being in the same room when they type it.

Comment by Andy "SuperFly" Rundquist — 2013 February 4 @ 04:23

• I’ve done in-class lecture/discussion (not hands-on) with all of them, and one-on-one tutorials with a few of them, with varying results. Some of the ones I had one-on-one tutorials with complained the most about how long it took them to do the assignment, but seem to have gotten everything right. Others remain clueless about gnuplot. Several of the top students have been helping each other out on learning gnuplot, which seems to work for them.

Scheduling a group tutorial might be difficult, given the already limited lab time. I’m trying to build more lab time into next year’s schedule, and to set aside one “lecture” a week for data analysis (learning gnuplot and model fitting). I think that part of the problem is that the students have never had to fit models to data before (though that should be a fundamental part of the physics and chemistry courses, it doesn’t seem to have been).

Comment by gasstationwithoutpumps — 2013 February 4 @ 08:23

2. This is a “programming course” approach, but might be useful anyway. I experimented with something similar to Mark Guzdial’s worked example approach, and foung it helpful for getting students to focus on a particular effect. I gave the students uncommented code, had them type it in and make sure it worked, then comment it themselves. They also had to compare with two other people (who had slightly difference code) and explain the differences. After they got the point, I gave them examples with a couple of deliberately useless or counter-productive lines of code; when they got to commenting that and found themselves writing that the reason that line of code was there was… “no reason,” I knew they had understood. If nothing else, their comments were very informative in letting me know what they didn’t know, and they got a bit of exposure to what I expected their code to look like.

Comment by Mylène — 2013 February 4 @ 19:18