SUNY Geneseo, Department of Computer Science

Lab 3

CSci 141 , Fall 2003

Prof. Doug Baldwin

Due Wednesday, September 17

Purpose

Background

If you create an instance of the Robot class and send it a move message, the robot pauses briefly and then moves forward. If you send the robot a move message but there is a wall in its way, it flashes momentarily and does not move. These two observations raise a question: which takes more time -- moving successfully, or flashing when a robot cannot move? Your overall goal in this lab is to plan and conduct an experiment that answers this question.

While this particular experiment need not be tremendously difficult, good experiments generally require more thought and care than it seems at first. Chapter 4 of The Science of Computing discusses some of the issues in computer science experiments in detail. You should be generally familiar with this chapter before starting this experiment. During the experiment, sections 4.5 and 4.7, on mathematical tools for controlling and estimating error, and measuring time in Java, respectively, may be particularly useful references.

Documentation on the Robot class is available on-line, at http://www.cs.geneseo.edu/~baldwin/sc/doc/. The files needed to use the Robot class are available in our folder on the Course Materials file server, or on the World Wide Web at http://www.cs.geneseo.edu/~baldwin/sc/Robot.java and http://www.cs.geneseo.edu/~baldwin/sc/RobotRoom.java.

Exercise

Design, carry out, and report on an experiment that allows you to determine whether it takes more time for a robot to move one tile when unobstructed, or to hit a wall.

There are a number of steps in any experiment, and it is worth thinking about each:

1. Hypothesis and prediction. While you could do this experiment with no a priori expectations about how it will come out, that is not the usual situation in experimentation, and having some grounds for expecting one outcome rather than another can, if nothing else, help you check your data and conclusions for plausibility. So start this experiment by deciding whether you expect moving or colliding to be faster. You can make this prediction based on past experience or casual observations of Robot objects, intuitions about which should be faster, etc. It is not so important that your prediction is right as that you have one at all, with some grounds for believing it.
2. Experimental procedure. This is where you have the most room to design something -- specifically, your experiment. You can decide for yourself what data to collect, how to measure it, what program to measure it in, etc. However, keep in mind the guidelines for experimental procedure in The Science of Computing. While not all will be relevant to this experiment (or to any single other), many will be very important.
3. Data and data analysis. Once you collect data, you will need to do some analysis of it. This may be as simple as averaging several measurements of each variable in your experiment in order to get an estimate of its "true" value, or, if you have an elaborate experiment, the data analysis may be quite elaborate itself.
4. Conclusions. You should have a clear conclusion. It needn't be a long conclusion, but it should say clearly whether your original prediction was right or wrong, what the actual times for moving and colliding are, and can comment on anything else you found interesting in the experiment.

Follow-Up

Turn in a written report on your experiment. I have no specific format requirements for this report, but I do have definite expectations about what it will cover. This report (and others you write about experiments) should contain:

1. A statement of the hypothesis and/or prediction you were testing in the experiment.
2. An explanation of how you did the experiment (i.e., your experimental procedure). Attaching a print-out of any code you wrote for the experiment can make this part of the report much shorter, because the code in computer science experiments often embodies much of the experimental procedure. If you attach code to the report, you can refer the reader to that code, and only write text in the report to explain those aspects of procedure that aren't evident from the code.
3. All of the data you collected. It is important to show the raw data so that a reader can check your analysis and conclusions if necessary, make their own judgements about error levels, etc. A table of the data you collected is often sufficient.
4. A description of, and the results from, your data analysis. Sometimes this can simply consist of a few additional rows or columns in the table of raw data. At other times, you will need some text to explain the analysis, and additional tables or graphs to present its results.
5. A statement of the conclusion(s) you reached from the experiment. This should at least state whether the experiment does or does not support the initial hypothesis, and why. It is also an opportunity to comment on or speculate about other things that occur to you as you review the experiment (for example, do your observations during this experiment lead you to new hypotheses or predictions? Are there further experiments that you now think would be worth doing? Improvements on this one?)

In any report, brevity and clarity are virtues. I will be unhappy with unnecessarily verbose reports, just as I will be unhappy with reports that are too short to adequately describe an experiment. I do not require specific lengths for lab reports, although a page and a half or two (not counting any code you include) is typically adequate.