The 2nd Annual Lazy yet Competent Internet ProgrammingContest

assert.h	io.h	mem.h	string.h
ctype.h	iostream.h	stdio.h	values.h
fstream.h	math.h	stdlib.h

• No fees

• Consultation with people other than the contest director is prohibited.
• Do not work in a team environment.
• Submit questions to lchs2@hotmail.com who will try tofathom an appropriate answer for you (and post it to the site page, if appropriate). Many times, the reply will often be a suggestion to read the problem more carefully.
• Any amount of consultation with written materials (such as programming books) is allowed (but this doesn't mean you canask someone to write an article on how to solve a problem, ofcourse). Do not ask someone where to look up an answer though, that counts as "consultation with people".
• Spend no more than three sessions solving problems (i.e., if you work one hour in a session, take a one hour break, and then work another hour, you have worked for two sessions).
• Spend no more than a total of five hours solving problems.
• Submit source code for the problems to the contestcoordinators via e-mail to lchs2@hotmail.com (see below for format).
• Solutions will be judged for correctness by running themagainst several (usually 5-15) different sets of input data. Pointsare accrued for correct solutions. Some datasets for a problemwill be worth more points than others. Solutions to some problemswill be worth more points. Judging will be performed expeditiouslybut could take two weeks to complete.
• Unless otherwise stated, your program must run no longer than 5 seconds for any test case on the judge's computer (approximately 166 MHz Pentium).
• It is NOT guaranteed that all possible legal datasets will be solvable within the time limit.
• The judges reserve the right to increase time limits duringgrading.
• Judges will not test all datasets against a program thatcrashes the computer for initial datasets.
• Decision of the judges is final.
• Do not cheat; it's no fun for anyone.
• Do not use inline assembler statements.
• Do not submit programs that use data files that aren'tsupplied by the contest coordinators.
• Do not use "temporary" data files.
• Keep in mind that this is neither a "tricky input" nor a "tricky output" contest, in general. Input and output formats are straightforward, though the input values may cause your program difficulty.
• Problems are intended to be algorithmic in nature, meaning clever algorithms and/or data structures may be needed to score full marks.
• All problems are intended to be straightforward (yet challenging); no problems are intended to have "hidden tricks" in them.
• Nevertheless, legal but complex datasets are fair game for testing.
• If you find a problem with wording or an ambiguity, documentyour assumptions carefully and move on. Send e-mail; we'll replyif we can.
• Any violation of the above rules will result in a penalty or disqualification.

Notes:

• We will be using automated grading procedures.
• The registration information at the front of the solution should be in precisely the same format as requested below. Otherwise, your solution could be lost. Be sure that each program has the same registration information.
• Programs that consist of essentially nothing more than print statements will not be graded.
• Special thanks to Rob Kolstad for providing the contest rules andRuss Cox's for providing files to catalyze the gradingprocedures.
• Special thanks to Josh Bao and Jon McAlister for providing the problemsand test data. Josh Bao is a freshman at Caltech, and Jon is a freshman at Standford.
• During the contest, feel free to send questions (one pere-mail please!) to lchs2@hotmail.com.
• All programs read their input from file INPUT.TXT; do not specify a complete path name in your "open" statement, just "INPUT.TXT".
• All programs write their output to file OUTPUT.TXT; do not specify a path name in your "open" statement.
• Remember that all your output should be written to the file OUTPUT.TXT. Do not clear the screen or print anything to the screen.
• Note that test data run by the judges will almost surely be more challenging than the test data supplied with eachproblem.
• Don't use any of C++'s Standard Template Library (STL) or any classes other than those provided by iostream.h and fstream.h. We're using a very old C++ compiler: it probably doesn't know about the special classes you want to use.
• If your source code does not compile without changes, your program will not be graded. The only exception to this is: we will fix source codes mangled by mail agents' treatment ofline wraps and the like.
• Don't use C's "bool" type. That is specific to Borland C/C++ 5.0. If you can compile your code under ANSI C, you're probably safe.
• The scorer will not compile with any command-line compiler options. You must set any relevant options using the appropriate method in the source file, as illustrated above. Note that not all command-line options are compiler options. In particular, don't bother specifying "-P" or "-P-" on the "#pragma option" line, as the compiler will not accept it.
  

• No special registration form is required. Each problem solution has,withinits submission, an entry form (see below). You enter when you send inyour solution.
• Submit your answers to problems via e-mail to lchs2@hotmail.com. Pleasesend precisely one problem's solution program per e-mail (i.e., sendthree separate e-mails for three problems, etc.). If you submit morethan one solution for a single problem, only the last one receivedwill be graded. That means if you find a bug after your submission, you can re-submit. This is dangerous ground, of course, since your newer program might, in fact, be worse than the previous one.
• Each solution e-mail submission should have the following format forthe e-mail message. SEND ASCII MESSAGES. DO NOT USE ATTACHMENTS orMIME ENCODING, fancy mail options, or anything else.
• In the subject line of the email, put your name and problem number.
• Submissions must have special comments separating sections of the mail;you must insert the three '#'s and the word that follows them. Thesecomment lines are surrounded by a single blank line. Here is the exactformat for submitting solutions.
  ### Program
  ... [any compiler options you use] ...
  
  ... [header comments -- see below for format] ...
  
  ... [text of program in C or Pascal] ...
  
  ### End
  
  

• Put comments precisely like the ones below at the front ofeach and every solution (after the `### Program' marker).
• Be sure your email address and name are always spelledprecisely the same way. We use the combination of email address andname as a unique identifier for you.
• Data after `### End' are ignored (e.g., signatures)
• Do not insert any extra blanks or blank lines.
• Put compiler directives just before the header (as shownbelow) but nevertheless after the `### Program' marker. Choose your directives based on your own experience.
  
  Here is the C/C++ header example:
  
  ### Program
  
  #pragma option -O2
  
  /*
  
  Problem: 1
  Name: Benjamin Pierce        (First name then Last name)
  Email: benjamin.pierce@mash.us
  School: Lazyboy High School
  Grade: 12
  Age: 17
  City, State: Crabapple Cove, ME
  Country: USA                          (three letters: CAN, COL, DEU, ROM, USA, etc.)
  
  */
  
  
• If you live somewhere that has a city but no state, please omit thestate. If your school system uses a notation like "Form 6" for olderstudents, please pro-rate your "Grade" by calculating the equivalentUSA school grade. In the USA: grade 10 students begin around age 15;grade 11 students begin around age 16; grade 12 students begin aroundage 17.
  
  Here is the PASCAL header example:
  
  ### Program
  
  {$G+,N+}
  
  {
  
  Problem: 1
  Name: Jean Picard                          (First name then Last name)
  Email: captain.picard@starfleet.ufp
  School: Lazyboy High School
  Grade: 12
  Age: 17
  City, State: LaBarre
  Country: FRA        (three letters: CAN, COL, DEU, ROM, USA, etc.)
  
  }