Welcome to the
\ifPRACTICE
 practice round for the
\fi
2012 ICPC Mid-Atlantic Regional.  Before you start the
contest, please take the time to review the following:

\subsection*{The Contest}

\newcounter{savedEnumi}

\begin{enumerate} 
\ifPRACTICE
\item There is one (1) practice problem.  Please submit solutions or
  request clarifications {\bfseries for this problem only.}  Unless
  you have a real question about the problem, please submit at most
  one clarification request, and at most two runs.  It is important
  that everyone have a chance to see how the system works. Even if you
  do not solve the practice problem, you should submit once just to
  practice with the system.

\item After (or even before) completing the practice problem, please
  read all of the notes listed here.  They are designed to help you
  solve the problems during the contest.

\else
\item There are eight (8) problems in the packet, using letters A--H.
  These problems are NOT sorted by difficulty.  As a
  team's solution is judged correct, the team will be awarded a
  balloon.  The balloon colors are as follows:
\input{balloons}
\fi

\item Solutions for problems submitted for judging are called runs.
  Each run will be judged.  
  
  The judges will respond to your submission with one of the following
  responses.  In the event that more than one response is applicable,
  the judges may respond with any of the applicable responses.

\begin{center}
\begin{tabular}{|c|p{4in}|}
  \hline
{\bfseries Response} & {\bfseries Explanation}\\
\hline
\hline
{\bfseries Yes} & Your submission has been judged correct.\\
{\bfseries Wrong Answer} & Your submission generated output that is
not correct %or is incomplete.
\\
{\bfseries Output Format Error} & Your submission's output is not in
the correct format or is misspelled.\\
{\bfseries Incomplete Output} & Your submission did not produce all of the required output.\\
{\bfseries Excessive Output} & Your submission generated output in
addition to or instead of what is required.\\
{\bfseries Compilation Error} & Your submission failed to compile.\\
{\bfseries Run-Time Error} & Your submission experienced a run-time error.\\
{\bfseries Time-Limit Exceeded} & Your submission did not solve the
judges' test data within 30 seconds.\\
{\bfseries Other-Contact Staff} & Contact your local site judge for clarification.\\
\hline
\end{tabular}
\end{center}

\item A team's score is based on the number of problems they solve
  and penalty points, which reflect the amount of time and number of incorrect
  submissions made before the problem is solved.  For each problem
  solved correctly, penalty points are charged equal to the time at
  which the problem was solved plus 20 minutes for each incorrect
  submission.  No penalty points are added for problems that are never
  solved.  Teams are ranked first by the number of problems solved
  and then by the fewest penalty points.
  
\item This problem set contains sample input and output for each
  problem.  However, the judges will test your
  submission against longer and more complex datasets, which will
  not be revealed until after the contest.  Your major challenge is
  designing other input sets for yourself so that you may fully test
  your program before submitting your run.  Should you receive a
  judgment stating that your submission was incorrect, you should
  consider what other datasets you could design to further evaluate
  your program.
  
\item In the event that you feel a problem statement is ambiguous 
  or incorrect, you may request a clarification.  Read the problem
  carefully before requesting a clarification.  

  If a clarification is issued during the contest, it will be
  broadcast to {\em all} teams.

  If the judges believe that the problem statement is sufficiently
  clear, you will receive the response, ``No response, read problem
  statement.''  If you receive this response, you should read the
  problem description more carefully.  If you still feel there is an
  ambiguity, you will have to be more specific or descriptive of the
  ambiguity you have found.


  You may {\em not} submit clarification requests asking for the
  correct output for inputs that you provide, e.g., ``What would the
  correct output be for the input ...?''  Determining that is your job
  unless the problem description is truly ambiguous.
  Sample
  inputs \textit{may} be useful in explaining the nature of a
  perceived ambiguity, e.g., ``There is no statement about the desired
  order of outputs. Given the input:~\ldots, would both
  this:~\ldots\ and this:~\ldots\ be valid outputs?''.




\item Runs for each particular problem will be
  judged in the order they are received.  However, it is possible that
  runs for different problems
\ifPRACTICE
(during the actual contest)
\fi
  may be judged out of order.  For
  example, you may submit a run for problem B followed by a run for
  problem C, but
  receive the response for C first.  

\textbf{Do not} request clarifications on
  when a response will be returned.  If you have not received a
  response for a run within 30 minutes of submitting it, {\bfseries
  you may have a runner ask the local site judge to determine the
  cause of the delay.}  Under no circumstances should you ever submit
  a clarification request about a submission for which you have not
  received a judgment.

  If, due to unforeseen circumstances, judging for one or more
  problems begins to lag more than 30 minutes behind submissions, a
  clarification announcement will be issued to all teams. This
  announcement will include a change to the 30 minute time period that
  teams are expected to wait before consulting the site judge.
  
\item The submission of abusive programs or clarification requests to
  the judges will be considered grounds for immediate
  disqualification.

\item The submission of code deliberately designed to delay, crash, 
      or otherwise negatively affect the contest itself will be
  considered grounds for immediate disqualification.    

\setcounter{savedEnumi}{\value{enumi}}

\end{enumerate}


\subsection*{Your Programs}

\begin{enumerate}
\setcounter{enumi}{\value{savedEnumi}}
\item All solutions must read from standard input and write to
  standard output.  In C this is scanf/printf, in C++ this is
  cin/cout, and in Java this is System.in/System.out.  The judges will
  ignore all output sent to standard error (cerr in C++ or System.err
  in Java).  You may wish to use standard error to output debugging
  information.  From your workstation you may test your program with
  an input file by redirecting input from a file:
\begin{verbatim}
program < file.in
\end{verbatim}


\item Unless otherwise specified, all lines of program output 
\begin{itemize}
\item must
  be left justified, with no leading blank spaces prior to the first
  non-blank character on that line,
\item must end with the appropriate line terminator
  (\verb#\n#, \verb#endl#, or \verb#println()#), and
\item must not contain any blank characters at the end of the line,
between the final specified output and the line terminator.
\end{itemize}
You must not print extra lines of output, even if empty, that are
not specifically required by the problem statement.

\item Unless otherwise specified, all numbers in your output
      should begin with the minus sign ({\tt -}) if negative, followed
  immediately by 1 or more decimal digits.  If the number being
  printed is a floating point number, then the decimal point should
  appear, followed by the appropriate number of decimal digits. For
  output of real numbers, the number of digits after the decimal point
  will be specified in the problem description (as the ``precision'').


  All floating point numbers printed to a given
  precision should be rounded to the nearest value. 
  For example, if 2 decimal digits of precision is requested, then
  0.0152 would be printed as ``0.02'' but 0.0149 would be printed as
  ``0.01''.

  In simpler terms, neither scientific notation nor commas will be
  used for numbers, and you should ensure that you use a printing
  technique that rounds to the appropriate precision.

  

\item All input sets used by the judges will follow the input format
  specification found in the problem description. You do not need to
  test for input that violates the input format specified in the problem.
  
\item All lines of program input will end with the
 appropriate line terminator (e.g., a linefeed on Unix/Linux systems,
 a carriage return-linefeed pair on Windows systems).


\item If a problem specifies that
      an input is a floating point number, the input will be presented
      according to the rules stipulated above for output of real
      numbers, except that decimal points and the following digits may
      be omitted for numbers with no non-zero decimal
      portion. Scientific notation will not be used in input sets
      unless a problem explicitly allows it.




\item Every effort has been made to ensure that the compilers
 and run-time environments used by the judges are as similar as
 possible to those that you will use in developing your code.  
 With that said, some differences may exist. It is, in general, 
 your responsibility to write your code in a portable manner
 compliant with the rules and standards of the programming language. 
 You should not rely upon undocumented and non-standard behaviors.

 \begin{enumerate}
 \item One place where differences are likely to arise is in the size of 
 the various numeric types.  Many problems will specify minimum and 
 maximum values for numeric inputs and outputs.  You should write your code with the understanding that, on the {\em judges'} machines:
 \begin{itemize}
 \item A C++ {\tt int}, a C++ {\tt long}, and a Java {\tt int} 
       are all 32-bits wide.
 \item A C++ {\tt long long} and a Java {\tt long} are 64-bits wide.
 \item A {\tt float} in both languages is a 32-bit value capable of 
    holding 6-7 decimal digits, though many library functions will be 
    less accurate.
 \item A {\tt double} in both languages is a 64-bit value capable of 
    holding 15-16 decimal digits, though many library functions will be 
    less accurate.
 \end{itemize}
 The data types on your own machines may differ in size from these, but if 
 you follow the guidelines above in choosing the types to hold your numbers,
 you can be assured that they will suffice to hold those values on the 
 judges' machines.
  

  \item Another common source of non-portability is in C/C++ library
  structures.  Although the C \& C++ standards are very explicit about
  which header file must declare certain std symbols, the standards do
  not prohibit other headers from duplicating or loading extra
  symbols. 

  For example, if your program uses both {\tt cout} and {\tt
  ifstream}, you might find that your code compiles if you only
  {\tt \#include~\verb!<!fstream\verb!>!}, because, as it happens, on
  {\em your} machine the {\tt fstream} header {\tt \#include}s the
  {\tt iostream} header where {\tt cout} is properly
  declared. However, you cannot rely upon the judges' machines having
  libraries with the same structure. So it is {\em your}
  responsibility to {\tt \#include} the appropriate headers for
  whatever std library features you use.
\end{enumerate}
\end{enumerate}

Good luck, and HAVE FUN!!!
