Nice tips *@Stanislav.*Thank you.
On Thu, Apr 3, 2014 at 12:41 PM, Stanislav Zholnin < [email protected]> 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/8258e667-4986-4845-83e5-7ee6f31d9b9f%40googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAN6UTawQXw%3D3vb0abUwLHYNtU%3DWo78UkUxBb0hTQDVf5qPd%3Djw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
