2010 Call for Problems

June 13th, 2010 | Categories: 2010 Regionals

The Southeast USA Regional Programming Contest will be held on Saturday 6 November this year, and I will once again be Chief Judge.

As usual, the Problem Selection Committee will be responsible for putting the problem set together. The PSC will also be responsible for judging, so problem providers won’t have to judge. Because of this, you can provide a problem, and also coach your team, and attend the contest with them at your chosen site. Anyone can submit a problem for consideration – however, although a problem submitter can also act as a coach, they cannot be a contestant, whether or not their problem is chosen for the set. In other words, if a student submits a problem, they are ineligible to compete.

Candidate problems should be e-mailed to me (at vanb@vanb.org). A statement of the problem is all that’s necessary, either in text or in MS Word format (right in the e-mail is fine). If you wish to include a solving program and/or test data, that’s very, very helpful, but not necessary. If you have a rough idea and want to talk about it, feel free to e-mail it to me, and I’ll be happy to work with you.

Problems should be sent by 13 September to be eligible for consideration. I’ll remind you again, but I’m sending out the call for problems early, to get you thinking!

Below you will find an excerpt from the Call for Problems issued from World Finals this year. It’s a good set of guidelines for candidate problems. If you are thinking of submitting a candidate problem for Southeast Regionals, you should read through it. I will add a couple of constraints of my own:

  1. The problem should be original. It should not be a restatement of a problem that has been used previously in the Southeast USA, or any other ICPC regional, World Finals, or other contest environment such as TopCoder or Google CodeJam. It also should not come from a book, such as “Programming Challenges.” If it has its own Wikipedia page, then it’s too well-known.
  2. The output for any given input should be unique. Try to add constraints to your problem so that there is exactly one answer for each input case.

Based on suggestions from last year’s regional contest, I have started a blog to talk about judging at our contest. It’s at:


Feel free to drop by and give suggestions – however, do NOT post candidate problems on this site. It is open to everyone, including students. Any problem posted on the site cannot be used in the contest.

————- Some excerpts from the World Finals call for problems: ————-

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. 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.
  6. Indicate the precision that is required for real results.
  7. 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.
  8. 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. 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.
  9. The problem description (excluding sample input/output) should generally require at most one page.

Submission of Problems, Solutions, and Test Data

  1. Use electronic mail and send all files as either MS Word documents, or flat ASCII.
  2. Do not put your name in documents, or the body of e-mails, 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.
No comments yet.
You must be logged in to post a comment.