Problem 1: Fuzzy Time 

    -- This caused more problems than I thought it would.  It's straighforward,
       but some test cases kept tripping some teams up.  In particular,
       it seemed like teams were trying to calculate the # of days first
       and subtract that from the # seconds and go from there.  That's
       fine if the answer > 2 days.  Giving exactly 24 hours tripped
       a bunch of solutions up.

       My solution calculates the # hours first.  From that, it calculates
       the number of days if required.  

Problem 2: Catalan Numbers 

    -- The problem stated that C (n) will fit within 64 bits.  C (36)
       is the largest that still meets this criteria.  While C (n) will
       fit within 64 bits there is no guarentee that intermediate
       results will fit within 64 bits.  If you choose to calculate
       the factorials (which is the easiest thing) you have to be
       careful about overflow.  All the failed submissions had this
       problem.  You can't calculate n=36 and do 72! in 64 bits...
       
       
       My solution runs through and eliminates
       factors from the factorials until we get down to a point that
       the answer will fit within 64 bits.

       As an example of how to handle large factorials like this, 
       consider n = 3.

       C (3) = 6! / [ 4! 3! ]

       Right away you knock out the 4! since 6! = 6 * 5 * 4!.  You're
       left with:

       C (3) = 6 * 5 / (3 * 2)

       You know the final answer is an integer.  Therefore the numerator
       must be divisible by the denominator.  What you can do is zip
       through the denominator, calculating the gcd of each number 
       in the denominator with the numerator and factor out any common
       divisors.  Keep going until you're down to 1 for the denominator.

       For this case, the gcd (3, 6) = 3, so we can factor out a 3 from
       both numerator and denominator, giving:

       C (3) = 5 * 2 / (2)

       gcd (2, 5) = 1 so nothing to do there.  gcd (2, 2) = 2 so factor
       out another 2.

       C (3) = 5 

       In the general case, the numerator would still have other factors
       present.  At this point you can go through and multiply them
       all out to find C (n).  

       
    -- There's also a recurrence relation for this, but that can be tricky
       because of overflow (it works ok up to about n = 33 but the last
       few will overflow unless you careful about the multiplication).

    -- A few creative people tried using long long double or some such
       variant.  That's fine, except the answer won't be exact.  You'll
       get the last couple digits wrong (see the output for examples -- and
       before any asks, I did check my program's output against 
       Mathematica)


Problem 3: Divisors 

    -- I thought this was going to be easier than it turned out to be.
       Most people had the right idea, you can find the factors by a
       loop like:

       for (i = 1; i <= n; i++) {
	    if (! (n % i)) { /* do something  */ }
       }

       but this is *NOT* fast enough.  It'll work for some test cases
       if run by themselves, but not all the test cases I gave.

       You don't have to go up to n (or even n/2).  Note that if 
       n % i == 0, then i is factor, but n / i must also be factor.  You only
       have to go the sqrt (n) to find all the factors using this
       tidbit of knowledge and then can sort (or use stacks like I did)
       the divisors.  Going up to n, or even n/2 will take too long.

    -- The problem explicitly said not to print a blank line.  I did
       fail a few submissions for print an extra blank line (I normally
       wouldn't do that, but, since it was stated in the problem, I did
       this time).

Problem 4: Valid Football Scores 

    -- There was a simple trick to this.  The only invalid score is 1.
       0 is obviously ok.  2 is ok because of the safety.   Any
       even number is now ok since (at worst) it can scored by the
       appropriate number of safetys.  3 is in because of the field
       goal.  Now because 3 is valid we can add any multiple of
       2 (the safety) and get all the odd numbers.  Therefore, only
       1 is invalid, everything else is ok.

    -- Most people saw the trick, but missed simple cases like 0 
       (which is a possible score and also valid input).

Problem 5: Unit Conversion 

    -- The tricky thing here is to realize you have to infer
       all the possible conversions.  You may given m -> cm and cm -> in.
       From that you have to infer cm -> m, in -> cm, m -> in and in -> m.
       It isn't too hard if you set things up in a 2-D matrix and keep
       track of what unit maps to what ids.

Problem 6: Toll University 

    -- This actually isn't too bad.  You can use a simple flood fill
       on the graph to update each node with the minimum cost starting
       from a given point.