% Rules for Duke Internet Programming Contest
% latex format
% Time-stamp: <11 Nov 93, 13:56:54>
\documentstyle[11pt]{article}

% Margins
\sloppy
\setlength{\textwidth}{6.5in}
\setlength{\textheight}{9in}
\setlength{\topmargin}{-0.5in}
\setlength{\oddsidemargin}{0pt}
\setlength{\evensidemargin}{0pt}

\begin{document}

\title{Contest Rules}
\author{Duke Internet Programming Contest}
\date{November 18, 1993}
\maketitle

\section{Concept}
The idea of this contest is to enable many people to participate in a
programming contest. We hope it will be fun for all involved, as well
as boosting interest in the programming teams involved in the ACM
programming contests. This contest is very informal, and we hope that
the contestants will compete in
this spirit. The success of the contest depends on the integrity of
the contestants.

You should also have received a copy of the guidelines describing the
details of how to participate in the contest.

This document consists of \pageref{lastpage} pages.

\section{Teams}
Teams consist of {\em up to\/} four people. There are three classes of
teams:
\begin{description}
\item [I] Novice programmers.
\item [II] Expert programmers participating as an individual.
\item [III] Expert programmers with more than one person on a team.
\end{description}
When you register your team at the start of the contest, you decide
which category in which you wish to participate.  The novice category
will contain some extra problems that should be easier to solve, and
the expert categories will contain extra problems which are more
challenging.  There will be a set of problems that are common to both
categories, as well.

\section{Contest specifics}
\begin{enumerate}
\item We will provide a set of problems to be solved. There will be
3--10 problems in the set. These will be provided to a local
contest administrator. 
\item The contest lasts three hours.
 The judges have the power to extend the contest if necessary.  
\item Each team may use only one terminal (or workstation). You may
use any type of computer you wish, but you must use our software to
submit your solutions. 
\item We will judge programs using the compilers or interpreters as
listed in the Table~\ref{langlist}.  A \dag{} indicates that the language
is interpreted rather than compiled.  See Section~\ref{langnotes} for
additional information on the specific languages.

\begin{table}[htb]
\begin{center}
\begin{tabular}{l|c|l|l}
Language & Compiler & Version & Libraries\\ \hline\hline
C & gcc & 2.5.2 & standard C, -lm \\
GNU C++ & gcc & 2.5.2 & standard C, -lg++ -lm \\
Sun C++ & CC (cfront) & 2.1 & default and -lm \\
Objective-C & gcc & 2.5.2 & standard C, -lobjc -lm \\
Pascal & Sun Pascal & 2.1 & default \\ 
FORTRAN & Sun FORTRAN & 1.4 & default \\ 
Scheme (Revised\footnotemark[4]) & scm\dag & 4d0 & slib 1d5\\
(Literate) Haskell & LML hbc & 0.999.5 & default \\
Perl & perl\dag & 4.036 & default \\
Icon & icont & 8.10 & IPL \\
Emacs Lisp & GNU Emacs\dag & 19.19 & default \\
Standard ML &  SML/NJ & 0.93 & smlnj-lib 0.2\\
Matlab & matlab\dag{} & 4.0a & default \\
Common Lisp & CMU Lisp & 17c & minimal \\
Ada & Meridian OpenAda & 4.1.3 & default \\
\hline
\end{tabular}
\caption{List of languages.}
\label{langlist}
\end{center}
\end{table}

\item You may use any editor, debugger, and windowing system.
If your program does not compile or run on our SPARCstation running SunOS
4.1.3, that is unfortunate for you.
\item No arguments will be passed to the program at run time.
\item You may work on the problems in any order, and submit them in any order.
\item You may use any books and other materials you wish, except electronic
copies of pre-existing code.  You may not use any code that is
on-line. This rule means you must type in all code you hand in.  You
may not use any program that generates code in the language which you
submit the program for judging.  For example, if you are using Haskell
as your programming language for a given problem, you may not use any
program that generates Haskell and submit the generated code.
\item You may test problems on your computer as often as you wish.
\item To receive credit for a problem solution, you must turn in the
source code for 
judging. The mechanism is described below. The response will be one of 
the following:
 \begin{itemize}
 \item Correct
 \item Incorrect Output
 \item Compiler Error
 \item Runtime Error
 \item Runtime Limit Exceeded (2 minutes wall-clock time on the
       judges' machine; this should not be an issue if your program is
       coded correctly).
 \item Submission Botch (something went wrong with how you submitted
       the program to us).
 \end{itemize}
It is possible that you receive a ``Correct'' response for a
submission that may later be ruled not to count.  For example, if you
are an expert team and submit a novice problem, the judging system
will score the problem like any other, but the score tabulating
program will reject it.
\item If a contestant believes that a problem is stated ambiguously
and requires clarification, the contestant may submit a question to the judges
(mechanism described below).  The question and its answer may be
provided to all contestants if it seems relevant.  A response to the
question is guaranteed, although the judges may refuse to answer any
question.
\item No discussion is permitted with people outside your team.
\item All input is read from {\tt stdin}, and all judged output
is to be written to {\tt stdout}.  Output to {\tt stderr} will be
ignored.
\item You are responsible for backing up your own code and for making
your own printed listings.
\item  Use only system include files (e.g., {\tt stdio.h}), as
necessary.  You may also use library functions as provided for the
language you are using.  The program should be self-contained: do not submit
multiple-file solutions. 
\item \label{resubmit} After submitting a judged run, you must wait
for the response before {\em re\/}submitting the same problem. A
severe penalty applies if you break this rule. You may, however,
submit solutions to  other problems while waiting for a response from
the judges.
\item Judges may disqualify any team not competing in the spirit of the 
contest. Examples of unfair practices are stealing files, impeding others, 
degrading performance, unfair use of software tools, adjusting system
clocks, etc. 
\item The decision of the judges is final.
\item The judges are not responsible for network or system failures or
delays. 
\end{enumerate}

\section{Mechanisms}
The mechanism for submitting judged runs and clarifications uses
electronic mail.  A set of programs are installed on your system that
take the name of your program file, problem number, and team number,
and sends the program to the judges.  Your response is returned through
e-mail, without code.  A similar program sends a clarification
request.  The exact programs and how to use them is described in an
accompanying document.  If you did not get a copy of it, ask your site
coordinator for one.

Clarifications and periodic scores are distributed by e-mail.

\section{Scoring}
\begin{itemize}
\item No prizes are awarded.
\item The team that has had the most problems judged correct at the end
of the contest will be declared the winner. There are separate
rankings for each category, as well as overall.  If more than one team
has solved the same number of problems, the winner is the one with the
fewest penalty points.
\begin{enumerate} 
\item Penalty points are assessed for solved problems only.  
\begin{enumerate} 
\item One penalty point is assessed for each minute from the beginning
of the contest until the problem was solved.  
\item The time of solution is defined to be the time of submission,
according to your local computer time. 
\item Twenty penalty points are assessed for each judged run. 
\item Fifty penalty points are assessed for breaking rule~\ref{resubmit}.
\end{enumerate} 
\item No penalty points are assessed for any problem which was not
ultimately solved.
\item The contest coordinators
reserve the right to adjust penalty points to allow for unforeseen
circumstances.
\end{enumerate}
\item The score is posted every half hour through e-mail. The
scores may be withheld near the end of the contest to keep the final
results a surprise.
\item The final results will be mailed out (we hope) within a
half-hour after the contest ends.
\end{itemize}

\section{Language Notes}
\label{langnotes}
Here we describe the details of how each language is going to be used
during the contest, as well as any notes that may be relevant to that
language.  Compiled languages are handled similarly to this:
\begin{verbatim}
  gcc foo.c -lm
  a.out <input.data >output
\end{verbatim}
and then the \verb+output+ file is tested for correctness.  The exact
link libraries specified are listed in Table~\ref{langlist}.
Interpreted languages (labelled with a \dag{} in the table) are
handled similarly to this:
\begin{verbatim}
  scm foo.scm <input.file >output
\end{verbatim}

Note that even though \verb+icont+ is an interpreter, it is treated like a
compiler since it creates an executable.

Emacs Lisp is interpreted with the command
\begin{verbatim}
  emacs -batch -l foo.el <input.file >output
\end{verbatim}
Note that the Emacs 19 \verb+(message)+ function writes to
\verb+stderr+, so use \verb+(print)+ or \verb+(princ)+ and direct
output to \verb+stdout+.  In Emacs 18, \verb+(message)+ wrote to
\verb+stdout+.

Programs written using Standard ML {\bf must} adhere to the following
conventions.  The entire smlnj-lib version 0.2 is pre-dumped into the
sml compiler image; all the functions defined therein are available
for your use.  The final statement of your submitted program must be the
following:
\begin{verbatim}
  exportFn("a.out",main);
\end{verbatim}
where {\tt main} may be substituted for the entry point into your
program.  This will create an executable file called {\tt a.out} which
can then be tested.  Your entire file will be compiled like this:
\begin{verbatim}
  smll < foo.sml
\end{verbatim}
where {\tt smll} is the sml compiler with the library already dumped
into it.

Matlab programmers should read input from the file {\tt matlab.in} and
write to the file {\tt matlab.out} instead of {\tt stdin} and {\tt
stdout} respectively.

People wishing to use the CMU Common Lisp environment provided here
should contact Alejandro Caro \verb+<acaro@whopper.lcs.mit.edu>+ for
the specific details of the environment.

Ada programs must have the entry point named {\tt main}.

\label{lastpage}
\end{document}