1998 ACM East Central Programming Contest --
Contest Environment

[logo]
Back to information on the whole contest.


The contest will be run according to ACM rules.

Each team will have access to one computer terminal in a laboratory. It should be possible for three people to sit around each terminal, with two people right at the keyboard. Tables will be provided in halls.

If anyone on your team has special needs (impaired vision, a wheelchair or anything else), please tell the UW contest organizers

The Overall Environment

The contest environment is essentially the same as it was in 1993 and 1994 when the East Central Regional Contest was held previously at the University of Waterloo (i.e. The Battles of Waterloo.) So the environment is robust, tested, and command-line oriented. Changes are being made to make it friendlier and easier to use. The contestant information document is up to date and complete, but needs to be made friendlier. The final version of that document will be included in the contest package that you will get at the University of Waterloo, but you should read it before coming to Waterloo.

Machines

The X terminals will be an eclectic mix of various normal X terminals and may be supplemented by NT and Mac machines running X.

All programs are expected to run on Sun UltraSparcs. The current plan is to use several 4-CPU servers for contestants and a 1-CPU machine for judging. With respect to the contest, these machines can be considered to be configured identically.

Editors

Available editors are vi, xedit and jove. jove is a limited version of EMACS. Maybe pico will be added, but it is not recommended. There are tutorials and DOS executables for editors used in the contest environment available.

Programming Languages

The programming languages for the contest will be C, C++ and Pascal. There are no plans to make Java available, even though it will be used at the contest finals. C++ will include iostream support, but people who are not experts with those classes are probably better off using gets() and the scanf()/printf() family of functions. The C++ string library and Standard Template Library (STL) will not be available. You are more than welcome to bring source copies to the contest, but the version of gcc (2.8.1 at last check) will not support all of the necessary features of templates. (Templates will be available, exceptions are uncertain at this point. Mail from people that know the state of templates and exceptions in gcc would be appreciated.)

In the contest environment, there is no need to include header files for C and C++. (All attempts to include header files will fail.) An up to date list of auto-included headers is available.

All programming languages will get the benefit of gcc's -O2 optimizations. This means that contestants can concentrate on algorithms, not code-twiddling, when they get `runs too long' responses.

Programs

Programs may not open any files. Instead, they read their input from stdin and write output to stdout.

Each program has a CPU time limit of 5 seconds on a Sun UltraSparc, and will run niced so that several spinning programs will not overwhelm the editors and compilers running on the machine. (If it is necessary to use more than one type of machine, time limits will be adjusted according.) Program output is limited to 100KB. Memory usage still needs to be determined, but will allow at least 10MB of stack and heap. These limits apply to programs run in either the contest environment or the judging program.

Judging

Cyborg. The Waterloo environment traditionally automated most parts of the judging process other than choosing the judgement. Now we have auto-judging capability with lots of support for examining the progress of auto-judging and selecting the circumstances under which the auto-judger will be invoked.

The choice of error messages is prioritized:

  1. Compile-time error
  2. Run-time error or runs too long (whichever comes first if there are multiple test cases)
  3. Incorrect output if any output is `dead wrong'
  4. Format error if all output is correct except for white space, spelling, punctuation, capitalization, precision and so forth
Format error responses requires a judgement call or matching the auto-judger's definition of `format error'. Hence they cannot be guaranteed or relied upon. They are considered to be a friendly hint.

If an empty file, code for the wrong problem or a duplicate of an earlier submission is submitted, it is possible for the file to be marked as an `erroneous submission'. Note that if it appears that the program might have been intentionally submitted more than once, it will not be unjudged.