Student Programming Contest

The goal of this contest is to provide a fun, challenging, and educational experience for our undergraduate students.

The team registration deadline is September 27, 2019.  All contestants must Register, either for the full conference or for the programming contest only. In addition, each contestant must be listed on a team registration form (available on the registration page).

 

Note: These rules are subject to change due to site considerations. Teams will be informed of any such changes.

 

Team Composition

Each team consists of at most three student contestants from the same institution. Teams of fewer than three contestants are allowed, but discouraged as they usually are not competitive.

A student contestant must be enrolled in an undergraduate degree program at the sponsoring institution with at least a half-time load. This rule is not to be construed as disqualifying co-op students, exchange students, or students serving internships.

 

Conduct of the Contest

Solutions to problems submitted for judging are called runs. Each run is judged as accepted or rejected by a judge, and the team is notified of the results.

Posting of contest standings will be suspended 30 minutes prior to the end of the contest to keep the final results secret. Notification of run status will continue until the end of the contest.

A contestant may submit a claim of ambiguity or error in a problem statement by submitting a clarification request to a judge. If the judges agree that an ambiguity or error exists, a clarification will be issued to all contestants.

Contestants are not to converse with anyone except members of their team and personnel designated by the contest director. Systems support staff may advise contestants on system-related problems such as explaining system error messages.

The contest is scheduled for 4 hours but may be changed in the event of unforeseen difficulties. Should the contest duration be altered, every attempt will be made to notify contestants in a timely and uniform manner.

A team may be disqualified by the contest director for any activity that jeopardizes the contest such as dislodging extension cords, unauthorized modification of contest materials, or distracting behavior.

At least six problems will be posed. So far as possible, problems will avoid dependence on detailed knowledge of a particular applications area or particular contest language.

During the contest teams will be allowed print out source code, debugging output, or any other file created during the contest.

Teams may bring any written (hardcopy) reference material. This can include textbooks, language reference books, printed copies of programs, etc.

 

Scoring of the Contest

A problem is solved when it is accepted by the judges. The judges are solely responsible for accepting or rejecting submitted runs.

Teams are ranked according to the most problems solved. For the purposes of awards, teams who solve the same number of problems are ranked by least total time. The total time is the sum of the time consumed for each problem solved. The time consumed for a solved problem is the time elapsed from the beginning of the contest to the submittal of the accepted run plus 20 penalty minutes for every rejected run for that problem regardless of submittal time. There is no time consumed for a problem that is not solved.

 

The programming languages of the contest will Java and C/C++. No other programming languages will be allowed.

A team is allowed to use one personal laptop (per team) with wireless access as their contest machine. Teams are on their honor not to use any resources on their laptop other than those created in programming enviroments used during the contest. Accessing files not created during the contest will result in immediate disqualification. A (single) lab workstation (per team) also will be available for those teams who do not wish to bring a laptop to the conference. Information regarding local site programming environments will be posted here when known.

Problems will be submitted for judging using the Taylor University Touche’ submission system. It is a web-based, interactive submission system not unlike PC^2. A short User’s Guide is available.

Some Touche’ specific things to be aware of (mostly taken from the Taylor University Programming Contest FAQ):

• To ensure every team is using the same set of library files, Touche’ strips out all files included by the submitted source and includes the following files (depending on language) into the judged source.
  • C: stdio.h, stdlib.h, string.h, math.h, malloc.h, ctype.h, assert.h, float.h, limits.h
  • C++: cassert, cstdio, cstdlib, cstring, cmath, cctype, cfloat, climits, iostream, iomanip, string, new, stdexcept, list, queue, stack, vector, map, iterator, bitset, algorithm, set
  • Java: java.lang.*, java.io.*, java.util.*, java.math.*

  The judged source file is compiled with gcc, g++, or javac as appropriate.

• All solutions must be stand-alone applications that expect all input from stdin and write all output to stdout. Stderr is not redirected, so all diagnostic and/or debugging messages output to stderr will be ignored by Touche’. Refer to the next item for information about trying to open other files.
• The following are considered “bad words” and are not permitted to occur in any form in a program: fork, exec (which includes execl, execlp, execle, execv, execvp, and execve via pattern matching), open (which includes fopen and popen via pattern matching), system, fstream (which includes via pattern matching ifstream/ofstream), socket, accept, listen, connect, mmap, and __asm__. This includes comments at this time, so be careful what you say in your code.Future versions may be smarter, but not currently.
• The solution must reside in a single file. For Java programs, classes should not be declared public. The Touche’ software has trouble with those because it likes to rename the files and Java requires public classes to have the same file name and class name.