If you can't create large input yourself - there is no way you can test beforehand. There can be different potential problems:
1. Your algorithm is just too slow from the beginning. You didn't come up with proper algorithm - this is clear fail. And this is the easiest to predict if you know algorithms - with experience you can generally answer the question "if I do it this way - will it run in reasonable time?" 2. Your algorithm is good, but because you didn't do 1-2 quick optimizations here and there it finished in 10 minutes instead of 4. This is in my opinion the worst situation. You solved the problem, your algorithm is correct. Sometimes you will face dilemma of spending another 5 minutes optimizing this small piece of code or trying Large input as it is - very difficult. The most important here is that you must know approximate timing of different operations in language of your choice. Sometimes simple choice of different looping technique, different array format or running the same array backwards instead of forward - if it is nested deep in you algorithm - can bring difference of x2, x3 times. Just yesterday I solved Round 1A 2011 "Killer Word" problem. I had good algorithm from the beginning, but my first implementation run in 19 minutes (too bad!), then I used Python's sets to make set intersection quicker. Runtime dropped from 19 minutes to 3.5 minutes. Then I turned on Multicore in my template and it went down further to one minute. Algorithm was the same, but first attempt was clear fail and last - reasonably good for this type of problems. 3. Your algorithm was not actually correct. Organizers of Codejam do it (my presumption) - they come up with some corner cases to catch common errors in algorithms. Some of those corner cases go into initial sample in problem description (I call it "baby-input"), more of them go to "small-input", and some end up in "large-input". So if you successfully solved small input it still doesn't mean that your algorithm is perfectly correct. In reality even solving large input gives just 99.99% probability that your algorithm is correct. No advice here - this is again "essence of competition" - contestant must be able to identify corner cases. Maybe I can give advise of reading input constraints. It's very rare when some input constraints are there for "fun". If something is there, then it was needed. If it says Y >= 0 then ask yourself what you algorithm will do if you get Y = 0 in input? I agree all this can be frustrating (I would say p.2 is most frustrating, while p.1 is least frustrating), but still remember main tag line: THIS IS FAIR because rules are the SAME for everybody. -- You received this message because you are subscribed to the Google Groups "Google Code Jam" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-code+unsubscr...@googlegroups.com. To post to this group, send email to google-code@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-code/d9ca0b56-5b08-46c8-8690-197059580342%40googlegroups.com?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
