FAQ - 2009 Rocky Mountain Regional ACM

Q. How many teams can be from one institution?

A maximum of four teams from any one institution is allowed.

Q. How many people can be on a team?

Exactly three.

Q. What languages & platforms will be used for the contest?

C/C++ and Java. The contest will be judged using pentium-architecture SuSE linux servers. See Portability Issues to consider if you are working from some other systems.

Q. What can we bring?

Books, printouts, scratch paper. Basically, nothing electronic, or electronically readable media. This includes pocket calculators and PDA's

Q. What do you provide?

Site specific, but your team will have a single workstation, be fed, and have access to a classroom (or part of one) or similar place to work in relative privacy.

Q. What problems should we do first?

Since the time penalty for each correct problem is from the start of the contest, you should get the easiest problems done first. Note that determining which problems are easy is part of the contest! Seeing how other teams are progressing on the problems can help your team determine this.

Q. What do we submit?

A single source file which (if correct) solves the problem. The source file name has very specific constraints:

• The base name will be specified in the problem statement, for example, it may be count.
• The extension should be .cpp for C++ programs, .c for C programs and .java for Java programs. If your site supports other languages, ask about the expected extension for those languages.
Thus a C++ submission for the count problem should be named count.cpp.

C and C++ programs must be console applications where execution begins from the main function with the prototype


int main(int argc, char *argv[])

Here are count.c and count.cpp example files and portability tips which count the number of lines in the input file (count.in) and report that number in the output file (count.out).

Java programs must be console applictations where execution begins from the main method in the public basename class. Thus the source file which solves the count problem should be named count.java and declare a single public class named count:

public class count {
  public static void main(String[] args) throws Exception
  {
    // TODO: solve problem
  }
}

The class should be defined in the default package. i.e. with no package declaration.
Here is the count.java example file which count the number of lines in the input file (count.in) and reports that number in the output file (count.out).

Q. How do we edit/compile/run our code?

Again site specific. Assuming you are using a unix-like operating system the least-common-denominator editor is probably pico, which you can run by typing


pico source file name

at the command prompt. emacs and vi have (many) more features, but a harder learning curve. xemacs, if available, is pretty easy to use and has a lot of features. Eclipse, KDevelop, or Visual Studio may also be available and have many features. Ask your site director.

To compile a C program using gcc:


gcc -g -lm -o basename basename.c



To run a C program in the current working directory:


./basename



To compile a C++ program:


g++ -g -lm -o basename basename.cpp



To run a C++ program in the current working directory:


./basename



To compile a Java program:


javac -classpath . basename.java



To run a Java program in the current working directory:


java -classpath . basename

Q. How do we test our code?

Here's a test checklist:



• Does it work correctly agains the sample data? Use diff (unix)
  diff myoutputfile.out exampleoutputfile.out
  or windiff (windows) to make a detailed comparison. Case and spacing matters!

  Note that some problems are nondeterministic, in that they allow for more than one correct answer for a given input. diff is inadequate for determining the correctness of such programs. The judges, of course, will not use diff to determine the correctness of such problems.

• Does it work correctly against additional test cases? The data set used to judge your problem will almost certainly be more complex than the data provided as an example. The judge data will conform to the specifications of the problem, however. Create other data sets to test the correctness of your solution before submitting a problem.
• Does it generate any additional output? Turn off any debugging statements before submitting the problem.
• Does it read and write the data correctly? The input is from the console, and the output is to the console. Use the console i/o to read and write your data. (in C use scanf/printf, in C++ use cin/cout, and Java use System.in/System.out).

  Q. How do we debug our code?

  More site specific. gdb is the command line debugger for C and C++ programs, and you might have ddd, which is a gui-interface for this. Read the banners and h is for help. The Java IDE should support debugging, otherwise think about print statements.

  Q. How do we submit a problem?

  Point a web browser to https://acm.mesastate.edu/team/index.php. Login with the the 7-digit phone number-like code. You cannot change this password for the duration of the contest. Choose "submit a solution".

  Q. When we submit a problem, what should we expect back?

  The time it takes to judge a problem depends on how busy the judges are and how hard it is to judge your specific submission. Once your submission is judged, your team should receive one of the following responses (through the status page)
  
  
  • CORRECT! Be happy!
  • Compile Time Error Submitted program will not compile.

    The judges will only compile using non-optimized and debugging options, and only link against the standard libraries, along with the math libraries (-lm). Don't expect more than that when your program is built to run against the judge data. Warnings generated by the compiler are ignored.

    Note that, by ignoring warnings, what might be flagged as a compile-time error may produce a run-time error instead.

    • C/C++The judges will only link against the math libraries (-lm) and use debugging code generation (-g).
    • Java
      • The judges will use the site-published JDK. Type javac -version to discover which version of the compiler you are using.
      • The main method must be declared from the public class basename.
      • To prevent consistency errors between the file name and the classes which it contains, use only the default package (no package declaration), and make no public classes.
    • Contact your site administrator about site-specific language support and conventions.

  If the submission compile, the judges will first attempt to run the submitted program on the sample input data provided in the problem statements, then on additional input data. Along with any error verdict consequent to running the program, the judges will indicate whether the verdict is based on a run using sample input data or additional input data. In the latter case, it can be assumed that the run on sample input data was successful.

  • Run-Time System Error Running the program resulted in a system error message or malfunction.
    This could be caused by exceeding a run-time memory limit or output limit which is specified for each problem.
    
    
  • Time-Limit Exceeded The program took too long to run. The time limits imposed will depend on the specific problem and on computer processor speed.
  • Presentation Error The output was almost correct, but differed from the required output by differences in white space and/or case. Check the formatting requirements!
  • Incorrect Output This is the most likely (and frustrating) possible outcome of an incorrect submission. This could be caused by a format error, a logic error, or a rounding error. If the error was generated against the example data, then you should carefully check that the output is exactly correct when your program is run against the example data. You should also make sure that the input and output file names exactly match the names specified in the problem statement.

  Q. How do we clarify a problem?

  Choose "submit a clarification" from the team login page.

  All substantial clarifications (i.e., not "please reread the problem") are posted to all teams. Check for clarifications on the problems!

  Q. How are teams ranked?

  Teams are first ranked by number of correct solutions: the more problems which are finished by a team, the higher the rank.

  Teams that have finished the same number of problems are then ranked by fewest penalty points: the fewer points, the higher the rank. The penalty points accrued for your team is the sum of:

  • 20 points for each incorrect submission of a problem that was eventually submitted correctly by your team.
  • The number of minutes from the start of the contest to the submission time of the correct solution to a problem.

  Example: The contest starts at 10:00 am; Team Zorbo, turns in problem 1 correctly at 10:43, makes two incorrect submissions of problem 2 before submitting a correct solution at 12:35, and makes 3 incorrect submissions for problem 3 without ever turning in a correct solution. The Zorbos would have 225 penalty points, broken down in the following table:
  
  

  Problem	Submission Penalty	Time Penalty	Total
  1	0*20 = 0	0:43 = 43	43
  2	2*20 = 40	2:25 = 145	185
  total	2*20 = 40	3:08 = 188	225

  Note that there is no penalty accrued for problem 3, since it was never submitted correctly

  Enjoy the contest!