Skip to content

Conditionals

2009 December 2
by Hélène Martin

Obviously, as I dive into high school teaching, I’ve been thinking a lot about mental models necessary for programming and about how to form these.  With 120 students of my own that I have had the opportunity to see through their very first line of code, their first loops, their first conditionals, etc, it’s become painfully clear that some students are much better prepared to think computationally than others.  This is old news to most people, but it’s just a much more intimate reality for me now.  I have no idea why, really… it’s not obviously correlated to their other grades or to their temperament.  It’s certainly not only the basement nerds or even the particularly interested — I have an superstar freshman girl in my AP class who I just learned ended up in my class by accident!

In my exams, I try hard to uncover what students’ current mental models are and have an opportunity to review them as necessary.  Although I know it’s unpopular among many, I have them write code on paper as well as solve mechanical code reading problems (Stuart is my hero and I steal all my ideas from him).  Reading their solutions is so eye-opening for me, especially since I can correlate with what I’ve seen them do at the computer.

I recently had my Creative Computing students take a Python quiz.  I asked them a fairly simple conditional problem to get them to define a function that takes parameters and check their conditional syntax.  Something interesting came out.  Here’s the problem:

Write a function choose_todo that takes two parameters: a temperature and a mood.  It should print what to do according to the following rules:

Temperature

Mood

Activity

60 or above

Happy

Go hiking

60 or above

Sad

Go fishing

Below 60

Happy

Go hiking

Below 60

Sad

Stay home

Ok, not particularly demanding or intellectually stimulating but the average and good students did this:

def choose_todo(temp, mood):
    if(temperature >= 60 and mood == "happy"):
        print "Go hiking"
    if(temperature >= 60 and mood == "sad"):
        print "Go fishing"
    if(temperature < 60 and mood == "happy"):
        print "Go hiking"
    if(temperature < 60 and mood == "sad"):
        print "Stay home"

And from EVERY exceptional student, we have:

def choose_todo(temp, mood):
    if(mood == "happy"):
        print "Go hiking"
    else:
        if(temp >= 60):
            print "Go fishing"
        else:
            print "Stay home"

I had the two happy cases be the same to see if they would recognize it, but I didn’t expect it to be such a black and white thing.  I pretty much could give this one problem and assign grades for the year.

The strong students somehow turned the problem around in their brain a bit more before starting to write than the others did.  Of course, the first solution isn’t wrong, it’s just… less satisfying?

This is not by any stretch of the imagination a skill that I explicitly taught.  I showed examples of concise code and discussed the advantages of making mutually exclusive options obviously so by favoring elif/else constructs over sequential ifs… but it was parenthetical at best.  Why do some people just ‘get it?’

Temperature

Mood

Activity

12 Responses leave one →
  1. December 2, 2009

    looks like the supposedly !strong students were just explicit, and did exactly what you asked. Answer correctly first, and quickly in a test situation, optimize later.

    • Hélène Martin permalink*
      December 2, 2009

      Oh, absolutely. I didn’t mark them down or anything… and I wouldn’t judge them as !strong based on the answer. That’s why I’m surprised at how predictive the question is. Students I know as strong gave the second answer and students I know as middle or weak gave the first. Systematically.

  2. December 2, 2009

    “I pretty much could give this one problem and assign grades for the year.”

    Yup. You’re differentiating between the good and the excellent, but the gap is even wider between those who get programming and those who don’t, and the test to distinguish between the two isn’t very complicated: link to codinghorror.com

    This gap persists at all skill levels by the way. The difference between an average professional programmer and an excellent one is immense. We see this all the time when giving take-home programming assignments during interviews. The results that come back invariably fall into one of three buckets: unacceptable, average or fantastic.

    • Hélène Martin permalink*
      December 5, 2009

      That coddinghorror article is a good one I hadn’t read — thanks for pointing out. Now I’m curious to give my students a pre-test before they ever write a line of code…

  3. Lauren Bricker permalink
    December 4, 2009

    I’m sure you’ve seen Stuart’s stuff on the mystery of b := (b = false) right? link to cs.washington.edu

    • Hélène Martin permalink*
      December 5, 2009

      Yes! I find it fascinating.

      I didn’t expect such stark differences on what I considered a pretty uninteresting question…

  4. December 29, 2009

    Hi. Did anybody write this?

    print “Go hiking” if mood == “happy” else “Go fishing” if temp >= 60 else “Stay home”

    • Hélène Martin permalink*
      January 3, 2010

      Ahh… good one. No, I didn’t see that, but it’s probably because I hadn’t shown them anything like it.

      That being said, I recently showed a couple of strong students and article on functional programming in Python and they really loved that syntax. Maybe it’s something I’ll teach more explicitly in the future.

  5. Michael Rosenberger permalink
    May 23, 2010

    Hmm…

    How about:

    def choose_todo(temp, mood):
    print([['go hiking', 'go fishing'], ['go hiking', 'stay home']][temp == 'below
    60'][mood == 'sad'])

    Less readable, probably runs slower than the if-elif-else ladder cause you have to pay for the object creation; I’m just bored and felt like writing an alternate solution :P

    Dave’s wins in terms of readability and elegance, though.

    • Hélène Martin permalink*
      May 23, 2010

      Michael! That’s gross!

  6. John Stout permalink
    January 8, 2011

    Suppose something with a similar structure were given to me in my alternative role at college as MIS developer rather than a quiz then I would go for the first solution, because if the conditions change I can change the code quite easily, and if someone were coming in to maintain my code they’d have a much easier time of understanding it.

    I’d feel that, if I chose the second route, I’d end up commenting it in a lot of detail, e.g., making it clear that mood could be “sad” which is clear from the first example, whereas the first route’s code is essentially self-documenting.

    John

    • Hélène Martin permalink*
      January 20, 2011

      Hard to say. I find the second easier to read, but I suspect it may be a personal thing.

      Agreed that using an elif and specifying the second condition would be better. But I think only having the 60 in there once is a maintainability feature — only one thing to change if the cutoff changes.

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS