CS 368-3 (2012 Summer) — Day 2 Homework

Due Monday, June 25, at the start of class.

Goal

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

Tasks

Use the basic Perl that you have learned to write a simple interactive game. You will use Perl features such as:

• Numbers and strings
• Variables
• Conditional statements
• Loops

The user will run the script, think of a number between 1 and 100 (inclusive), 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 any legitimate answer eventually.

If you use a binary search, there is a simple Perl expression that we have not discussed in class but that may be helpful. Specifically, you can find the integer portion of a floating-point number like this:

my $x = int(23 / 5);

One last hint: This is a fairly short program. My version is about 30 lines total, including blank lines and so forth. Your solution may be a bit longer, that is fine, but if you find yourself at 100 or more lines, you probably need to rethink your solution.

Testing

Testing your code is very important! If you do not run your code, you will make mistakes and probably not receive full credit. And even just running your code once may not be enough. Try different cases and make sure things work as you expect.

Here are some specific tests to consider:

• Pick the number 42 and see if your script can guess it.
• Can your script guess the number 1?
• Can your script guess the number 100?
• What happens if the user (you) cheats and lies about whether each guess is too high or too low?

Reminders

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

#!/usr/bin/perl
# Homework for CS 368-3
# Assigned on Day 02, 2012-06-21
# Written by Your Name

use strict;
use warnings;

Do the work yourself, consulting reasonable reference materials as needed. Any resource that provides a complete solution or offers significant material assistance toward a solution not OK to use. Asking the instructor for help is OK, asking other students for help is not. All standard UW policies concerning student conduct (esp. UWS 14) and information technology apply to this course and assignment.

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 — that is, pretend that you are the computer. 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; imagine that the upper limit is 1,000 instead of 100!

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 reduce by 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 computer science jargon 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. Use lots of print statements to check your assumptions about what your script is doing; that is, print the value of your variables:

  print "\$x : '$x'\n";

• 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:

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

• 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 script 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 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 scripting features 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 features 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.