I think the problem set came out a little harder than I had intended.
I didn't think problem 2 would be as bad as it was.  I did think
alot of teams would get problems 1, 2 and maybe 3 with a few more
getting one of 4, 5 or 6 (4,5 are just long. 6 requires Dijkstra's
algorithm).  Looking back, I probably should have yanked off either
4 or 5 and put another on.

When submitting your problems during the ACM contest, please make
sure of the following:

    1.  Take out any debugging statements before you submit.  You'll
	get back some cryptic responses from the judges if you don't.
	One time you could get "Too much output" and another time get
	"Wrong answer".

    2.  Unless otherwise stated, all solutions read the input data
	until the end of file is reached.  Some problems may include
	a special flag to let you know the end is near, others may not.


Problem 1: Alternating Sums. 

Problem 2: Semi-perfect numbers.  This one caught me off guard.   I didn't
   intend for it to give such huge headaches concerning the time limit.
   That said, I did notice a number of people tried to find the divisors
   of x by running d from 1 to x, inclusive and doing whatever when x%d
   == 0.  Yes, this will give you the divisors, but it also covers a
   whole bunch of numbers that you need not check.  You only need to go
   to sqrt(x). If you find a d such that x%d == 0, then you know that d
   and x/d are both divisors.  You do have to make a quick check to
   make sure that d and x/d are not equal before summing both (e.g. for
   4, the divisors are 1, 4 and 2, 2.  2 is only summed once, as in the
   example in the problem).  You can get a bit fancier with where you
   stop the factoring.

   My solution for this is in two parts, as I wasn't sure about fitting
   all of this within 2 minutes.  The first one went through all the
   numbers from 2 to 65000 and figured out which Semi set each number
   belonged to.  Turns out this part took just over a minute to run on
   the machine I'm at (same one the judging was on).  The output from
   this program was an array that listed the n for each number.  The
   actual solution then just runs through and finds the largest n in
   the range.  The final solution runs in under a second.

   The case that bombed everyone was 2 65000.  For that case if you
   calculate the divisors by running a loop from 2 to the number,
   you're going to do 65000^2 iterations, which will put you over
   the time limit.  Other interesting things can happen if you think
   too much about the Semi sets.  When I thought of the problem, I
   initially (and naively) thought that n may be bounded by the
   number itself.  Turns out that's not the case.  But you don't
   see this until you get into larger numbers (hundreds).

   Moral of the story: always check the extreme cases.  If needed,
   write a program to calculate the most extreme case, let it run
   for as long as it needs, and then hard code the answer into 
   the solution you submit.

Problem 3: Football scores
  I'm not sure what all people were bombing here.  I think some were
  not counting all the cases correctly with the touchdowns.  For example,

  8 -1 -1

  is 4 because you can get that by 4 safeties, 1 touchdown + saftey (no 
  PAT or 2 pt conversion), 1 touchdown + 2 pt conversion, or 2 field goals
  + safety.  I think what people were missing was that the touchdown
  can happen in 2 different ways for this case.

Problem 4: Baseball Standings
Problem 5: Following the Grateful Dead

   I don't think either of these were particularly hard.  They're
   just obnoxiously long and require alot of book keeping.  If you can
   wade through that, you can nail the problem.

Problem 6: Powerpuff Girls
  
   Use Dijkstra's Algorithm on the graph.