Contents:

• Collaboration Policy
• Overview
• The Challenges
• Testing Your Implementation
• Submitting Your Assignment
• Grading Standards
• Extra Credit

Collaboration Policy

For this assignment, you must work individually in regard to the design and implementation of your project.

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

Overview

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 (details).

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 unambigous 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.

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 your own
  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.

  Although the program is formally written to to accept input from standard input, it can be quite tiring (not to mention, error-prone) to have to type the test input each time you want to run your program. For some problems, the test input is also quite large.

  It is possible to redirect input from a text file to the standard input without needing to rewrite your source code. On our system, this can be done with the following syntax if working from within a console window:

  	python gnome.py < myInput.txt
  	

  This behaves just as if someone were to type the characters from the file myInput.txt on the keyboard while the program executes.

• Testing on judge's data (on turing)
  When you have the program working on the sample data and you wish to test it on the judges hidden data, you may execute the following command from your turing account.

  	/Public/goldwasser/150/practice/judge gnome.py
  	

  (of course, using the actual name of the source code file). Our automated program is not quite as professional as the real judges, but it will do. In particular it does not automatically terminate after 60 seconds elapse. In fact, it never terminates. It will tell you when it starts executing. If too much time has passed, you may press cntr-C to kill the process yourself.

  Also, a correct distinction between "wrong output" and "presentation error" is difficult to automate. We've made a decent attempt to look for common presentation errors, but in case of doubt, we will report it as a "wrong output".

Submitting Your Assignment

Although the online tools give you a way to test your implementation, you must formally submit your program through the course web page in order to get credit. Please submit separate files for each problem (gnome.py, dup.py, rps.py, )

You should also submit a separate 'readme' text file, detailing how much time you spent on each of the challenges.

Please see details regarding the submission process from the general programming web page, as well as a discussion of the late policy.

Grading Standards

The assignment is worth 10 points.

Extra Credit

Time for one more challenge?

Easier Done than Said? (say.py)