Thursday, June 26, 2008

Call for Problems - 2009 ACM International Collegiate Programming Contest Finals

Provided by Dr. C J Hwang; ACM-ICPC Asia Director;
Professor of Computer Science, Texas State University, Texas

Call for Problems - 2009 ACM ICPC Finals

All problems must be submitted by Friday, July 25, 2008.

2009 ACM International Collegiate Programming Contest Finals
Call for Problems
The ACM International Collegiate Programming Contest is seeking
programming problems for the Contest Finals. Contest Finals Judges
will be selected from among those who contribute problems. Each
contributor must submit at least two problems, each consisting of
* a problem description,
* a solution in C/C++ or Java
and * a simple test plan.
All problems must be submitted by Friday, July 25, 2008.
This date is firm and cannot be extended.

I will send an acknowledgement when I receive a submittal. If you do
not receive an acknowledgement within a week, please contact me again.
The "Guide for Judges and Problem Contributors" is attached. Please
read this document carefully.
If you have any questions or comments, please contact me.

Dick Rinewalt Computer Science Dept Texas Christian Univ
Guide for Judges and Problem Contributors
2009 ACM International Collegiate Programming Contest Finals

Judges for the 2008 ACM International Collegiate Programming Contest Finals
have the sole responsibility for producing the test problems (including test
data and expected results) used in the contest and for assessing the
correctness of solutions produced by teams competing in the contest. This
guide is an attempt to assist judges with those responsibilities.

Problems from previous Contest Finals are available at the URL
These may be used as further guides for producing problem statements.
If you have more questions, please contact:

Director of Judging
Dick Rinewalt
Department of Computer Science
Texas Christian University Box 298850
Fort Worth, Texas 76129
Office phone: 817-257-7166

Problem Statements
1. Each problem must be unambiguously described in English.
2. All problems must require input.
3. Unless the core of the problem is input/output related, the formats chosen
for input data and the displayed results should be relatively simple.
Still, the format of the input data and the appearance of the expected
displayed results must be described in suitable detail.
4. Multiple data sets testing different cases are appropriate; make the
problem statement include iterative data sets as input to avoid using
separate input files.
5. Due to the judging environment, a problem which requires more than one
input file is not appropriate.
6. Anticipate questions about special cases. Where appropriate, explicitly
state that certain special cases will not appear in the input data. It is
not necessary to specifically identify the special cases that will appear.
7. Indicate the precision that is required for real results.
8. Contestants must write solutions for problems in a short time. While very
simple problems are not appropriate, neither are problems that require a
great deal of code; a few hundred lines of Java or C should be an upper
limit on what can be expected in a solution.
9. The program and chosen test data should not require excessive execution
time. Contestants' solutions may be less efficient than yours and so a
generous margin is allowed for execution. Still, if your test data
requires the program to execute for a long time, then incorrect student
solutions (e.g., those with infinite loops) will take an excessively long
time to judge. We would like to avoid those situations.
10. The problem description (excluding sample input/output) should generally
require at most one page.

Judges' Solutions
1. For each problem you propose, prepare a solution in C/C++ or Java.
Solutions in multiple languages will be appreciated.
2. Include comments in your code, even though the contestants' code need not
be commented.
3. Make sure that your program correctly solves the problem! Include test data
that illustrates the generic and special cases that you expect the
contestants' solutions to handle.

Test Data

1. Data must be unambiguous when printed. Consider carefully those cases where
trailing blanks (or leading blanks, etc.) will make a difference in a
program that processes input data.
2. If several test cases are included, describe the manner in which data for
the test cases is separated in a single file.
3. Include a rationale for each of the test cases you provide. This will help
identify missing test cases as well as identify those cases where a student
solution fails.
4. Put a copy of the sample input data first followed by general cases, ones
which student solutions are likely to get. Stress tests (boundary values)
should appear last.

Submission of Problems, Solutions, and Test Data

1. Use electronic mail and send all files as either
* MS Word document,
* RTF,
or * flat ASCII.
PGP encryption is encouraged but not required.
My public key is attached to the end of this message.
2. Do not put your name in documents containing the problem statement,
solution, or test data. This will simplify the transformation from your
form to the one used for ranking.
3. Be discreet about problem statements and solutions. It is not appropriate
to discuss problems with people not involved with the contest.
4. Problem selection will be completed around September 1.

Judging Criteria at the Finals

1. Each solution proposed by a contest team will be judged as acceptable or
not. If not, at least one of the following comments will be returned to the
* Run-time error
* Time limit exceeded
* Wrong answer
* Presentation error

2. Contestants may ask for clarifications of the problem statements. When
appropriate such clarification will be provided.

Each proposed problem must include the following components:
a) A problem statement.
b) A correct C/C++ or Java solution to the problem.
c) A comprehensive (but not necessarily exhaustive) annotated test data
set for the problem.