CS 368-4 (2011 Fall) — Day 2 Homework

Due Tuesday, November 1, at the start of class.

Goal

Write a Python script that plays a simple number-guessing game with the user.

Tasks

Use the basic Python that you have learned to write a simple game program.

The user will run the script, think of a number between 1 and 100, and then the script will repeatedly guess what the number is. For each guess, the user indicates whether it is correct, too high, or too low. A typical interaction might look like this (the human user’s input is highlighted in yellow):

Welcome to the number-guessing game!
Think of a number between 1 and 100.

I guess 50.
Is this (c)orrect, (h)igh, or (l)ow? h
Too high, I'll guess lower.

I guess 25.
Is this (c)orrect, (h)igh, or (l)ow? l
Too low, I'll guess higher.

I guess 42.
Is this (c)orrect, (h)igh, or (l)ow? c
I got it!

While a binary search is clearly the optimimal strategy here, it does not really matter what strategy your script implements as long as it is guaranteed to find the answer eventually.

Reminders

Start your script the right way! Here is a suggestion:

#!/usr/bin/env python

"""Homework for CS 368-4 (2011 Fall)
Assigned on Day 02, 2011-10-27
Written by <Your Name>
"""

Do the work yourself, consulting reasonable reference materials as needed; any reference material that gives you a complete or nearly complete solution to this problem or a similar one is not OK to use. Asking the instructor for help is OK, asking other students for help is not.

Hand In

A printout of your code, ideally on a single sheet of paper. Be sure to put your own name in the “<Your Name>” part of the code. Identifying your work is important, or you may not receive appropriate credit.

Hints For New Programmers

Most importantly: Start early! Give yourself time to make mistakes, get stuck, and eventually work things out.

Before writing any code, think about how you would play this game, especially when you are guessing the other player’s number. Do you start guessing at 1, adding 1 to your guess each time you are wrong? No, not unless you want the game to take a very long time. Instead, you probably guess 50 and then ask whether you are correct, too high, or too low. Why 50? Because it is halfway between the highest possible number and the lowest possible number. Once you know whether you are too high or too low, you effectively cut in half the range of possible numbers. That is, your definition of “highest possible number” or “lowest possible number” changes, and then you apply the same process over again.

This is a good strategy for your program to follow, too. The fancy computer science term for the approach is binary search.

So, now that you have a general idea of the approach, you need to start organizing your thoughts into code. Here are a bunch of techniques that you can use; use some of them, or all of them together!

• Bottom-up design. Have an idea of how to write some of the code? For this assignment, I bet you can get your script to show those first two lines of output when it starts. Go ahead, type it in! Do you remember how to ask the user for input? Type that in, too! At first, if you have coding ideas, just type them in and do not worry if they work well together. If you have an incomplete idea, write the code in a line that is a comment (i.e., starts with #). The whole point of bottom-up design is to start with little bits of code that you know, and then build up the rest of the program around them.
• Incremental development. Did you write a line or two of code yet? Great! Run your script now. Does the new code work? If so, yay — time to move on! If not, try to get the new code to work before moving on. That is, develop your code in small increments, maybe just one line of code at a time, and make sure things work at each increment.
• Pseudocode. Stuck for ideas? Try writing your program in English, one instruction at a time, as comments in your script. Put each distinct instruction on a separate line. If you are a bit unclear about how to do something, write it as clearly as you can at the moment. As much as possible, try to write your instructions like code, but do not worry if you need to resort to plain English for some parts. For example, here is pseudocode for a simple temperature conversion script:

  # degrees_fahrenheit = get user input with prompt "Enter degrees Fahrenheit:"
  # degrees_celsius = ... [how do I do this?]
  # print "Degrees Celsius =" and degrees_celsius, formatted

• Top-down design (or decomposition). The idea here is to design your program in a small number of very big steps first, then break the big steps into smaller steps, then break the smaller steps into even smaller steps, and so forth until the individual steps correspond to a single Python statement. For example, here is a very high-level design for a program that calculates some statistics for a file full of data (note that I am using pseudocode, as described above):

  # read data file
  # for each record of data, add the data to the statistics
  # calculate summary statistics
  # print results

  Once you have the big picture, think about each step. Can you take one big step and break it into smaller pieces that get closer to being real Python code? For example, suppose your pseudocode for this homework assignment has a step like, “guess number”. Can you break that down? Maybe something like, (1) calculate new guess from highest and lowest possible numbers, then (2) print guess. Now those smaller steps are getting closer to things you know how to do.

• Pragmatism. Think about the Python that we just learned: numbers, strings, variables, assignments, conditionals, loops. You can probably guess that I designed the homework to work on those things. Where might these aspects of Python fit into the solution? Consider variables. They store values for later use. In this problem, what is some information that comes at one time and is used later? Or, thinking another way, what information changes over time as the program runs? Next consider conditionals, the if statement. It is used to make decisions and perform different behaviors based on the decision. Where does this program need a decision? What is that decision? For each possible result of the decision, what happens next? And so forth.