Self-correcting tests

I'm in the midst of grading finals (450 Students: I'm about halfway done) and noticed a rather disturbing pattern. Either I have not gotten to my 450 students or my students are lazy. I don't know that there is any other alternative.

I assigned a problem on the final exam which requires the students to examine a C++ program and it's generated assembly. Then, to take three statements in the program and justify the calculations performed in the assembly. For example, given "int a [3
[2][3] of int" in long form) explain the assembly for "a[i][i][i]". Anyone who's messed with C or C++ knows that the calculation involved is mechanical, but not completely trivial. It took me several days to work out all the rules via reverses engineering, but I taught the students those rules and they've had so much practice they should have them memorized by now (or at least should have by the final---it's probably lost already for some).

Anyway, the justification required means the students perform a short proof of the statement showing the raw address calculations that must be performed to calculate the array location. The second half of this, is going line by line through the assembly and showing that the same calculations are performed. At the end of each, you should have calculated the same address. In the simple example above, you would have calculated "a + i*24 + i*12 + i*4" where a would be replaced with some raw address (EBP-80 would suffice for the address here).

The great thing about this test question is that it is self-correcting. If a student gets a different calculation for the assembly than for the proof, the student knows there's an error and can go recheck her work and find the mistake and correct it. There's always the chance that you could make the same mistake in both places, but this is rare.

Okay, all of this is to get to the point that many of my students answered the question lazily or "cheated." (Cheated in the sense that they lied about what they found to match a bad answer, not as in committed academic dishonesty.) Some found different answers and then didn't bother to correct the error. Others obviously altered their interpretation of the assembly to match a bad proof calculation or vice versa.

It's not as if these students were out of time either. Only two students actually stuck around until the end of the test period. I have kept the papers in the order they were turned in and the first turn in came about forty minutes before the end of the two hour test period. Many of these lazy/cheating tests came in 15 to 20 minutes early.

Furthermore, it's not as if these students didn't understand what was going on. I gave them sheets giving detailed explanations of each assembly instruction included on the test for reference. Most of the papers were by students who did most of the work correctly, but made a simple mistake in their math or elsewhere that they could have corrected if they'd studied their solution further.

I am dyslexic, so I understand the frustration of making typos and math errors. I make them frequently. I am used to going back and fixing such errors. Perhaps this age of computers has aggravated the "spellcheck" problems that my high school teachers used to accuse my generation of being susceptible to (i.e., we couldn't spell if we didn't have spellcheck to save us).

Maybe we should start students programming in an environment where they have no garbage collector, no protection from resources, and where mistakes hang the computer. I learned on DOS and while the segfault did not exist, there were many occassions where an illegal memory access, deadlock, or write to BIOS resulted in immediate reboots or system halts. You learned pretty quick to be extra extra careful about wild pointers. Maybe we need more of that to help our students along.

I dunno, maybe like generations before me I'm just the masochistic old man saying, "When I was a kid, I had to walk to school through the snow, into the wind, uphill both ways, 50 miles, barefoot, over glass..."