COSMOS Summer 2006, Lab Exercise 1: Intuition

Introduction

This lab exercise is all about intuition. I'd like you to take the opportunity to exercise and develop your intuition in two settings today:

Testing an existing program, which I'm providing, to see how many ways you can find to cause it to behave incorrectly or in ways that you think are inappropriate. Notice that the problems you'll find are often caused by the fact that the computer has no intuition about the meaning of its calculations, or the general meaning of your communication with it, beyond what is stated in the program. (I intentionally left a number of problems in the program, but I'm sure you'll probably find others that I didn't intend.)
Interacting with IDLE, the Python interpreter that we'll be using throughout this course. In addition to becoming more comfortable with the environment so that you'll be ready to use it, I'd like you to use your intuition to discover the meaning of some Python statements that we'll be talking about later this week. Notice how inflexible the interpreter is in dealing with statements that are mistyped, structured incorrectly, or contain other seemingly minor mistakes.

The moral of this story is that there's no reason why computers or programming should be intimidating. You're the one in the driver's seat, and you're armed with intuition and a broader understanding of the world around you; the computer, on the other hand, awaits your instructions and has no malicious intent (or any intent at all!). The challenge in communicating with a computer — via an existing program or when writing a program of your own — is largely caused by what we talked about in lecture yesterday: Computers are dumb! Keep this in mind as you work today, and throughout this course.

Pair up!

Before proceeding, be sure that you have a partner. (Because we have an odd number of students, one group should have three students, and the others two each.) If you don't, talk to one of the course staff and we'll help you find a partner for today.

There are a few rules that I'm asking you to follow regarding paired or group work during this course.

One member of the pair or group, at any given time, is the driver; the driver is the one who has the keyboard and is able to type. Feel free to pass the keyboard between you if someone has an idea that he or she wants to explore, and be sure that the keyboard is changing hands every fifteen minutes or so.
You may only use one computer per pair or group. Even if you're not the one who has the keyboard in front of you, I want you to be fully engaged in the work of your pair or group. Believe it or not, you'll learn just as much, even if you're not the driver.
It is the responsibility of all group members to be sure that all the other members of the group are understanding what's being done, which means that I want you to be talking to each other throughout, explaining what you're doing, why you're doing it, and why you think it's the right thing to do. If you're understanding things quickly, or if you've encountered some of these things before and are already familiar with them, that's fine, but don't move forward in the lab exercise until everyone clearly understands what's happening.

Remember: The objective here is not to get the work done as quickly as possible; you have roughly three hours today to explore this topic, so savor it, talk about it, explain it to each other, and be sure you and your team are getting what you came for.

Part 1: Finding bugs in an existing program

In computing, we often refer to problems (e.g., misbehavior, crashing) as "bugs." In many industry settings in which software is built, there are people on the team whose sole job is to test the software and find bugs in it. Today, I'd like you to spend some time in that role, to give you the feeling about how you find bugs. Most often, they'll be caused by the fact that computers possess no intuition about what's "right" or what's "reasonable," so that if the program uses the wrong formula to perform some calculation, or if it does not contain special instructions about what to do in cases that are out of the ordinary, the computer will still blindly follow the instructions that have been given to it. Armed with this knowledge, you'll likely find writing your own programs to be easier; the trick, early on, is to have the right set of expectations of what the computer can and can't do.

Download the following program to your computer, saving it on the desktop, so that you can easily run it repeatedly by double-clicking it. If you're not sure how to do that, ask one of the course staff and we'll be glad to help you.

The Program

Find as many bugs as you can in the program. I've intentionally made some mistakes, and I'm sure I've also made some unintentional ones as well. Note that "finding a bug" isn't just a matter of noticing that something is wrong. You also need to specify how to reproduce the problem — what set of steps did you take that led to the problem? — and, as specifically as possible, what the problem is. It's important to be specific about it, since you may not be able to find the bug again — and, in a programming context, wouldn't be able to fix it — if you don't know exactly how you found it. Take a systematic approach, rather than randomly typing input and seeing which input crashes the program; try to anticipate what may cause problems, rather than just guessing.

As you find bugs, write descriptions of them — what the problem is, what set of steps causes it, why you think the behavior you're seeing is incorrect — in a Microsoft Word document. (If you're not sure how to start up or use Microsoft Word, please don't hesitate to ask us; we're happy to help!)

Part 2: Experimenting with Python using IDLE

IDLE, as we saw in lecture yesterday, is the interpreter that we'll be using as we write Python programs. Like any interpreter, IDLE translates Python statements into "machine code," the instructions that the computer understands but are difficult for us to write, then translates the results of the computer's computations back into a readable form to show them to us. In order to use IDLE, you need to know how to "speak Python," which is the primary subject of this course.

We'll begin to cover Python in detail during tomorrow's lecture, but I'd like you to spend some time today familiarizing yourself with the IDLE environment and getting accustomed to typing statements and seeing results. Along the way, I'm going to show you some Python statements — some correct and some broken — and ask you to do the following for each of them:

Read the statement with your group.
Discuss amongst yourselves what you think it might do and why. (This is where the intuition part comes in. If you already know Python, it would be good to wait until the other member(s) of your group can use their intuition to make an educated guess.)
Type the statement into the interpreter. (It may seem strange, but I'm asking you to type it, rather than copy and paste it; I'd like you to have the chance to make mistakes along the way and see what happens when you do, so please type it by hand.)
See whether the result matches your intuition. If not, why do you think you got the output you got? (One way to test theories about the output you got is to try variants of the statement to see how they behave. If you prefer, you can go to www.python.org and have a look around.)

Here are the Python statements that I'd like you to discuss and type, in the order presented. Take your time with these, and be sure to talk about them before executing them. It's okay if you don't get through all of them. It's also perfectly okay (and normal, in fact) if your intuition about them is totally wrong sometimes; I don't expect you to know what they all mean. But you'll be surprised how much you will have learned, heading into tomorrow's lecture, from having gone through this exercise.

    "Hello!"

    2 + 6 * 3

    (2 + 6) * 3

    2 + (6 * 3)

    8 / 2

    7 / 2

    8.0 / 2.0
    
    7.0 / 2.0
    
    3 ** 4
    
    -3 ** 2
    
    6 % 3
    
    7 % 3
    
    8 % 3
    
    9 % 3
    
    10 % 3
    
    z = 10
    
    z
    
    z + 10
    
    z = z + 1
    
    z

        Notice that the next one will wait for you to type input
    
    numOfPeople = input("Number of people in class: ")
    
    name = "Alexander William Thornton"
    
    name[1]
    
    name[8]
    
    name[0]
    
    name[10:16]
    
    name[10:17]
    
    dictionary = {}
    
    dictionary["program"] = "A set of instructions to be given to a computer"
    
    dictionary
    
    dictionary["program"]

    x = 20
    
        You may find that you have to hit the Enter key a second time before
        the interpreter will accept some of these
    
    if x == 20: print "Hello!"
    
    if x == 30: print "Hello!"
    
    if x < 30: print "Hello!"
    
    if x > 30: print "Hello!"
    
        These statements consist of more than one line each; type them
        exactly as you see them, hitting the Enter key at the end of each
        line.  You will probably have to hit Enter an extra time at the
        end of each.
    
    if x != 30: print "Yes!"
    else: print "No!"


    if x == 10: print "Ten"
    elif x == 20: print "Twenty"
    else: print "Thirty"
    

    a = 1
    
    while a < 10:
        print a
        a = a + 1

    for i in range(0, 10):
        print i

That's it! Way to go! Feel free to experiment further, if you have the time.