1998 ACM East Central Programming Contest --
Problem Input

Back to information on the whole contest.

This is our declaration of what we won't do to you. Everything else is fair game. If we need to violate this for a problem, it will be explicitly mentioned in the problem definition. We would only do this if what we were trying to accomplish in the problem did not violate the spirit in which the the declaration was intended.

Kiss Your EOF Problems Goodbye

Waterloo teams are used to reading input from standard input and detecting the end of file. It isn't very hard. However, this completely blew some teams out of the water at previous regionals held at Waterloo.

At this contest you will still read from standard input, but we will be nice about the input format. Instead of specifying `read in a list of integers and sort them', the first line in the file would contain an integer that declared the number of integers to be read. If there are multiple test cases, the number of cases will be given or they will be terminated by a sentinel value. In general, we will try to make input look like it did at the 1998 regional contest.

Lines Will Be at Most 80 Characters

Actually, that isn't necessarily true. But if a question requires input with lines that are longer than 80 characters, then the problem statement will mention this. So, if you are asked to read a line containing several integers, there can't be more than 40 of them.

Note that the `80 characters' doesn't include the newline and ASCII NUL characters that a C programmer would get using fgets(). In that case, a buffer of 82 characters would be necessary. (Experienced contestants don't calculate these numbers precisely. Instead, they automatically allow some slack and allocate buffers of size 100, or maybe 1024.)

No Extra Whitespace

If you put extra whitespace in your output, it is a format error. If we put it in the input, programs may crash or give wrong output. So there will not be any blank lines or spaces in the input that are not mentioned in the problem definition. Exactly one space will be used between input values on a line and there will be no spaces at the start or end of lines.

No tabs. Not ever.

Trivial Input Parsing

Unless parsing is the problem (`parse FORTRAN statements' or something similar), input will be trivial to parse. You should never need to do anything more complicated than read in a line, use spaces to divide it into tokens and figure out which parts are strings and which are numbers.

No Equality Comparisons on Reals

Any problem that requires floating point equality comparisons on derived reals is bad. So we won't do it. Equality comparisons on numbers that are known to be equal are fair game. Some examples:

Known Numbers -- Okay

Each line of input contains a floating point number and an integer. Sort the lines by the floating point number; break ties using the integer.

Derived Numbers -- Bad

Given a set of points and lines specified by floating point numbers, output all of the points that lie on any of the lines.

Your Fault for Doing It Wrong 1

The above problem, but with integer coördinates. There is no need to use any floating point numbers.

Your Fault for Doing It Wrong 2

Does a line segment intersect a polygon? We have no problems with making the line go through the vertices of the polygon in the test data. If you use the easy (and bad) algorithm of checking to see if the line goes through any of the lines in the polygon, your program might fail.

Note that there is no excuse for poor computer math. For example, don't be tripped up by simple things:
(10¹⁷-10¹⁷)+10^-17=10^-17
10¹⁷-(10¹⁷+10^-17)=0
10¹⁷⁰*(10¹⁷⁰*10^-170)=10¹⁷⁰
(10¹⁷⁰*10¹⁷⁰)*10^-170=+Inf
Let's not even think about the horrors of division.

Input Number Size

Input integers will be at most 2³¹-1, the maximum signed integer in all of the supported programming languages.

Ambiguous Output

Problem specifications will mention if there is ambiguous output, although this might be limited to `output a set of integers that satisfies the constraints and has minimal size'.

Output of Floating Point Numbers

This always gets ugly, because some form of rounding will be required. Just round to the nearest number of the appropriate precision. The judges will make sure that floating point error is allowed for so that you don't need to worry about what happens if you need to round 17.5 to the nearest integer, for example.

As before, if you elect to switch to floating point numbers when integers would work, any problems that arise are your own.