So you basically just use the small input/output set as test cases when doing the optimizations for the harder problem; clever, and a helpful tip, thanks! ;)
As for going for the simple strategy, I agree. Sometimes you don't need any special optimization. I tried a couple of practice problems, and even though I knew there could be a better solution, the solution that I had worked perfectly even for the large inputs. Actually, that was the reason why I had initially started this thread - I knew the code wasn't optimized even though it worked for the large input, and was wondering if optimization carried any extra weight and was required even in this case. So, I guess it's all down to experience - which means practice, practice, practice - the more experience you have, the better your chances at identifying when a particular algorithm is just good enough for both the small and large inputs. On Thursday, April 3, 2014 9:11:18 PM UTC+5:30, Stanislav Zholnin wrote: > I would like also to add that I often use the following tactics: > > Very often for small input much easier algorithm / implementation does the > trick. Sometimes you can even come up with brute force and solve it withing > approved time. What I often do is doing program for small input as simply as > possible - no difficult algorithms, no optimization, straight. In my case > (and probably it is the same with many people) this approach is less prone to > errors. > > After I submitted small input and ensured that it is correct, I switch my > helper code template to "verify mode" - this is very helpful and you should > include it into your working code template. What it does is it runs the > program, but instead of writing answer file it checks new answer against > those which are in the file. > > After switching to this mode I start making adjustments to algorithm / > optimizations. Everytime I run it I see if my program still produces correct > results. > > In majority of cases, if I did all adjustments I wanted and it still produces > correct output for small case it will produce correct output for large. There > are things which can go wrong - yes, but it is always the case. > > Alternative I am trying to avoid here is the following: > Trying to implement best possible algorithm from the beginning possibly with > several bugs and several small inputs used to clear up those bugs. Every > small input is a time penalty. Very often avoiding just one time penalty > already gives enough time to write simple straightforward solution. > > Good example of this approach - problem from round 1C last year - Great Wall. > It is C problem, so was the most difficult in a round. Small input is very > easy - you just write program as it is written in problem statement. Large > was difficult. But if you already have set of input/output you know to be > correct, making adjustments to algorithm trying to make it faster is > much-much safer. -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-code/5569dd0f-9d45-4a2c-b71e-c290cec7f042%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
