Some miscellaneous thoughts about the problem set and individual
problems.

General: Looking over the results, this problem set apparently
came out harder than I had intended.  The problems I thought
would be easier to do, turned out to give teams fits due
to issues with reading input, or some tricky math.
The only general advice I can offer for those issues is to
be extremely careful about working with floating point
numbers.  Avoid it if you can.  Never compare for exact
equality because there's a good chance the comparison will
fail in odd ways (that is, it may actually work sometimes,
and other times it'll fail even if the number is the same).

Problem 1 (Big-O) and 3 (Pitcher ERA) were examples of
this.  They were intended to be more straightforward and 
weren't designed to hang up teams.  (Problem 5 and 6 on other hand ...)

More specific thoughts:

Problem 1:

-- Using 64 bits didn't seem to be a problem, but the 
   math messed people up.  Order matters.  You can't
   do something like:  n2_time = (N / 1000) * N.
   That'll fail if N was an int because there were N was smaller
   than 1000, but N^2 was not.  (e.g., N = 700.  700 / 1000 = 0
   by the rules of integer math, but N^2 / 1000 = 490)

-- Order of ceil messed up some solutions.  I tried to
   give a pass on the problem if that came up.

==========================
Problem 2: 

-- Lots of failed solutions here.  The input was trying all
   possible team numbers from 1 to 99 and again from 99 to 1.
   The second of those seemed to cause more problems and I'm
   not sure why.  I'd have to track it down with specific
   solutions.

==========================
Problem 3:

-- I intended this problem to easier and not give teams grief.
   It didn't work out that way.  There were a couple problems.

   The first was that teams did not interpret 0.1 and 0.2 as
   1/3 and 2/3 of an inning, respectively.  Some solutions simply
   did 9 * earned_runs / innings without translating the 0.1 to
   0.33333333, and so on.

   The second was that 0.33 and 0.66 are not good enough
   approximations to use.  The final answer was to 2 digits, but
   to get there, you generally need to use more.  I didn't work
   out how many you needed at a minimum (it's probably at least 4).
   But if you used the approximations given in the problem, you
   should have been fine.

   The biggest problem was reading in the input.  That messed
   up a lot of teams.  (That wasn't something I expected.)  There
   are lots of ways to handle it; you can take advantage of how
   limited the input was.  So for instance, my solution reads
   the innings pitched as w (an int), then reads off the '.' as
   a character, then reads off the remaining int as p.  This method
   took advantage of the specific formatting given in the problem
   spec.   Other ways to do it including reading the input as
   a string and processing that in some way.  You can read the
   value as a double (or float), but you need to be careful with
   the processing.  You can't test for "<= 0.1" or something like that
   to catch for 0.1.  The equality check could fail.

   BTW: the case that messed up people was 14 earned runs in
   2.1 innings pitched.  That works out to 14 * 9 / 2.333333 = 54.00

-- While I'm at it... The problem spec says to print the ERA
   to 2 decimal digits.  I wasn't as strict about this as I
   should have been, but at the regional the judges will be.

   If the spec says 2 decimal places, then printing "54" is
   wrong.  It should be "54.00".  Again, I wasn't as picky
   on this as I should have been.  Just be careful about this
   at the regional.


==========================
Problem 4:

-- One team tried it.  One team got it.

   It's a straightfoward graph problem, but a graph problem
   nonetheless.  You can look up various algorithms for
   handling it (like Floyd-Warshall or just a breadth first
   search).

==========================
Problem 5:

-- Yeah.  Ok.  I did intend this problem to be the hardest one
   on the problem set and it turns out I was right.  There's
   a dynamic programming solution for it.  If you can see your
   way to the recursion, you can nail it.  (There's other ways
   as well.)  

-- There are notes in the source file on how to setup the
   dynamic programming solution.

-- It was hard and there were lots of failed submissions.
   My advice is the following:


   IF YOU FAIL A PROBLEM A BUNCH OF TIMES, GO ON TO SOMETHING ELSE!

   I know it's hard to do, but banging your head against the wall
   on one problem at the expense of all others will cause you
   great frustration.  It happens though (it happened to the team
   I took to the World Finals a couple years ago.  Sigh.)

   You need one of your team mates to tap you on the shoulder and
   kick you off the problem to work on something else.  If you have
   a bright insight later, then go for it, but don't focus solely
   on one problem.  You may accidentally pick the hardest problem
   to focus on and not see any of the other (easier) ones.

==========================

Problem 6: 

-- The problem is easier than it looks.  There's a ton of verbage
   in the problem spec, but if you get past all that garbage,
   you'll find that the problem comes down to moving the Wumpus
   and agent around in the maze in a prescribed fashion.  (The movements
   are given to you as input.)  You just have to follow out the
   cases.