In this lab, you will start working with if statements and while statements. At the end of the lab, you'll find a larger project that will be due in two weeks.
To start the lab, make a lab3 directory inside your cs124 directory. Copy TextIO.java into the lab3 directory. (Remember that you already have a copy in lab2, so you can copy it from there.)
Also copy the data file /classes/f09/cs124/icecream.dat into your lab3 directory. You will need this file for the third exercise of the lab.
The three exercises from this lab are due at the beginning of next week's lab. To turn in your work, copy your lab3 folder into your homework folder in /classes/f09/cs124/homework.
The first exercise of the lab uses an if..else statement. Write a program that simulates rolling two dice, trying to roll a pair (where the values on the two dice are the same). The program should roll two dice. The program should print out the two values that are rolled. If the values of the two dice are equal, the program should tell the user, "You got a pair!". If the two values are different, the program should tell the user, "Sorry, you didn't get a pair."
Note: Use an if..else statement, not two if statements! (You should be able to explain why the if..else is more efficient.)
The second exercise for the lab is "Silly Division." Division is sometimes said to be repeated subtraction. For this program, you will write a program that computes the quotient A/B and the remainder A%B by repeatedly subtracting B from A.
The program should first read in two positive integers, a and b from the user. (You can assume that the user really does enter two positive numbers. You don't have to test them, but you might want to think about what happens when the input data is bad.)
Use a while loop to repeatedly subtract b from a as long as the value of a is greater than or equal to b. Each subtraction simulates removing a pile of b things from a. When this loop ends the final value of a is the remainder when the original a is divided by b.
The quotient of the original a divided by b is the number of times that the while loop executes -- that is, the number of piles of size b that you can remove from a. Add a counter variable to the program to count the number of times that the loop is executed.
At the end of the program, print out the quotient and remainder.
Each line of the file icecream.dat is an ice cream flavor such as "Vanilla" or "Strawberry." A line represents the sale of one ice cream cone of the given flavor.
The third exercise of the lab is to write a program that does the following: The program reads the file icecream.dat, using TextIO. Count the total number of ice cream cones that were sold. (This is the same as the number of lines that you read from the file.) Also count the total number of "Strawberry" cones that were sold.
At the end of the program, print out the total number of cones, the number of Strawberry cones, and the percentage of cones that were Strawberry.
Note: To do this program, you have to know when to stop reading from the file. TextIO has a function named TextIO.eof() to check whether the entire file has been read. The value of this function is true if the entire file has been read. The value is false if there is more data in the file. You want to continue reading from the file as long as TextIO.eof() is false.
Note: Suppose that flavor is a variable of type String and you want to test whether its value is "Strawberry". To do this, test whether flavor.equals("Strawberry"). (Don't use == to test for equality of Strings.)
This section describes a project that is longer and more complex than the usual lab problems. This project is not due with the rest of Lab 3. Instead, it will be collected separately, in two weeks. This project requires some techniques that we have not yet covered, so you should not expect to be able to complete it immediately after this lab. We will discuss the project in class. However, you can begin thinking about the problem and working on the program design now.
The project is to write a program that will administer a ten-question arithmetic quiz to the user. There can be addition, subtraction, multiplication, and division problems. The questions should be appropriate for elementary school students who are just beginning to learn arithmetic. For example, all the numbers should be integers. The number of digits for addition problems should be at most two. For multiplication problems, at least one of the numbers should be a one-digit number. For subtraction, the answer should not be a negative number. For division, the answer should be an exact integers, so that a problem like 28 / 5 would not be possible.
For each of the ten problems, you should pick the kind of problem -- addition, subtraction, multiplication, or division -- at random. You should also make up the problem at random. So, for an addition problem A + B, you should choose A and B at random. Present the problem to the user and get the user's answer. You can compute the correct answer and check the user's response. If the user gets the problem wrong, tell them the correct answer. At the end of the test, tell the user how many problems they got right.
(Hint: For a division problem of the form A / B, you can pick B and the answer at random, and then use those two numbers to compute the value of A. This will give a division problem where the answer is an even integer.)
You should be trying for more than just a program that works! The program should have I/O that looks nice and makes it easy for the user to tell what is going on. It should be friendly to the user. (This is for kids!) The program itself should, of course, be nicely formated and commented and should follow all the other rules of good programming style.
Extra credit opportunity: Give the user two chances to get each problem correct. If they get it right on the first try, they get full credit (10 points). If they get it right on the second try, they get half credit (5 points). If they don't get the correct answer in two tries, tell them the correct answer, and don't give them any points. At the end of the quiz, instead of telling the user how many problems they got right, tell them how many points they got, out of a possible 100.