Contents:

• Collaboration Policy
• Overview
• Logistics
• Practice Problem
• Test Your Implementation
• Submitting Your Assignment
• Extra Credit

Collaboration Policy

For this assignment, you must work individually. You may discuss concepts (not answers) with other students, but all code implementation must be done entirely by you.

Please make sure you adhere to the policies on academic integrity in this regard.

Overview

Topic:   Functions and Loops
Related Reading:   Chapter 5

This assignment is worth 10 points.

Rather than one large program, this assignment involves a series of smaller challenges. All of these are problems that were used as part of the ACM International Collegiate Programming Contest (ICPC). Each Fall, teams from SLU compete in the Mid-Central Regional qualifier.

Each problem is computational in nature, with the goal being to compute a specific output based on some input parameters. Each problem defines a clear and unambiguous form for the expected input and desired output. Relevant bounds on the size of the input are clearly specified. To be successful, the program must complete within 60 seconds on the given machine.

Each problem description offers a handful of sample inputs and the expected output for those trials as a demonstration. Behind the scene, the judges often have hundreds of additional tests. Submitted programs are "graded" by literally running them on all of the judges' tests, capturing the output, and comparing whether the output is identical (character-for-character) to the expected output.

If the test is successful, the team gets credit for completing the problem. If the test fails, the team is informed of the failure and allowed to resubmit (with a slight penalty applied). However, the team receives very little feedback from the judges. In essence, they are told that it failed but given no explanation as to the cause of the problem, or even the data set that leads to the problem.

Actually, the feedback is slightly more informative. Upon submitting a program, the team formally receives one of the following responses:

• Success

• Submission Error
  This is reported if the submitted program does not properly compile, is not properly named, or is clearly an attempt at a different problem.

• Run-time Error
  This is reported if the program crashes during execution.

• Wrong Answer
  This designates that the program ran to completion, but the content of the output does not match the expected results.

• Presentation Error
  In spirit, there are some cases where the students got the wrong output not because their computations were wrong, but due to a superficial problem in formatting their output. This can occur if they misspell words, use incorrect or missing punctuation, capitalize incorrectly, use too few or too many spaces or extra blank lines, or present the wrong number of significant digits in numeric output.

Logistics

1. Your source code must be saved in a file with a particular name, as specified in the problem statement. For example, the first problem for the homework must be solved using source code in a file named gnome.py (note the lowercase).


2. Rather than getting input from a user through the raw_input function, we will assume all input is to be read from a file. We will cover more about files later in the semester. All you need to know for now is the following. You can create an object for managing the file using a syntax such as

   manager = open('gnome.in')   # creates a file manager

   where the precise file name to be used is specified in the problem statement (e.g., gnome.in). Subsequently, you can read a line at a time from that file using the syntax

   line = manager.readline()    # returns the string of characters



3. Because data is being read from a file rather than a user, you are not to print any prompts requesting input (such prompts will confuse the automated grader).


4. Your must produce output that matches character-for-character the expected output. This means you need all spacing, punctuation, capitalization and so on to match the stated format.


5. Most of the problems are stated in a way so that a single execution of the program solves multiple cases of the problem. Make sure that your program does so (presumably by having an outer loop to handle the multiple test cases).

A Practice Problem

Adding Numbers (add.py)

The Challenges

• Gnome Sequencing (gnome.py)

• Duplicate Removal (dup.py)

• Rock, Paper, Scissors (rps.py)

• Speed Limit (speed.py)

Testing Your Implementation

• Testing on sample data
  Since each problem specification includes at least a few sample cases of input and the expected output, there is no reason to submit your program to the judges until you are confident that it succeeds on those sample inputs. To help you out, we have already typed up those sample input files; they are available for download here. Of course, you are also welcome to add your own tests cases to the input file to more thoroughly test your program. (The judge's certainly will!)

• Testing on judge's data (on hopper.slu.edu)
  The judges for the contest will test programs on many cases beyond those that were given as samples. Fortunately, we have all of the judges' tests available on our system...

  We're not going to do this part. Just submit your program when done testing with the given input.

Submitting Your Assignment

Please submit separate files for each problem: gnome.py,   dup.py,   rps.py,   speed.py

You should also submit a separate 'readme' text file, with the requisite information.

You should submit these files electronically by emailing them to the instructor.

Extra Credit

Time for one more challenge? We will award an extra point if you solve Easier Done than Said? (say.py)