rezaulhsagar's blog

By rezaulhsagar, history, 8 years ago, In English

Hi all!

This is my first entry on Codeforces. Ignore my bad English.

Over the last few weeks my contest performance was terribly poor. It's not the fact that the problems are too much hard. Even I can solve it on paper in less than 10 minutes with implementation. Then after coding, I submitted and and got several WAs.

The mistakes were too funny. Not clearing vector elements, not using parenthesis in an equation, displaying wrong variable, using a[i] instead of i bla blah... :(

I have a strange mentality. During contest time, I feel I need to solve quickly. As my friends are solving Div-2 A in less than 15 minutes, I feel embarrassed to be the lower ranked on the table. So, after seeing WA in a pretest, I want to debug quickly. I use a long long instead of int, resubmit, WA again in same pretest. (Isn't it funny?)

I don't want to quit problem solving. But, this is too frustrating when I make same mistakes over and over again. I hate being gray.

Is there any remedy against it? Should I stop taking part in contests for some time?

Any suggestion?

[frustrated emo]

  • Vote: I like it
  • +47
  • Vote: I do not like it

| Write comment?
»
8 years ago, # |
  Vote: I like it +54 Vote: I do not like it

Try contests in virtual participation and resubmit only after understanding why you got WA. Not even once "maybe it's long longs, let's see". It should help you.

Even more hardcore strategy: resubmit only when you find a test for which the previous code is wrong and your new one is right.

You think too much and stress too much. As I said, try virtual participation. It's something slightly less stressful — maybe a good start.

»
8 years ago, # |
  Vote: I like it 0 Vote: I do not like it

I am in the same situation as you I guess. In codeforces round #356 I knew how to solve problem B and I coded up a solution but I did not notice the '<' char in my REP macro and assumed it to be '<=' cause of which I ended up getting WA on test 3 but then I changed the macro after the contest and then it started working. I couldn't debug it during contest (note: my code was only failing one testcase) and spent all of my time on solving B. I knew how to solve C as well but by then the time was up :'( .

  • »
    »
    6 years ago, # ^ |
      Vote: I like it +1 Vote: I do not like it

    My suggestion is that Don't use much more macro. You can use typedef ... But don't use macro for loops.

»
8 years ago, # |
  Vote: I like it +3 Vote: I do not like it

I have been gray for a long time. Now I am green(xD). And I realized that most important thing is don't worry. If you wanna be a good competitive programmer, you need to learn a lot. And sadness only stop your learning. For myself I remember one thing: "The most interesting thing in your goal is a way to the goal". Good luck :)

(Sorry for my poor English)

»
8 years ago, # |
Rev. 2   Vote: I like it +27 Vote: I do not like it

I had exactly the same problem. I think to cure this problem you should change your mindset about problem solving in general.

Here is my thoughts:

You can not solve a problem faster than your current level is. Do not care about speed right now, do care about correctness. Speed is something which slowly improve overtime as your brain develops "cache".

Try to not submit solution for problem "A" earlier than 90 minutes even if you are sure that it will work.

During these 90 minutes write clean and easy to understand code. Do not look at other's participants hard to read code. You should care about correctness, not speed right now.

Before testing your code read it and think how your code works. Then manually test your code on edge cases. Think slowly on different edge cases. Also, before you submit solution you can read problem statement again to check that you actually get it right.

Prefer not debug your code if you have wrong answer. It's better to read problem statement and code and think where you could make mistake.

When you get correct solution in first submission in five contests in a row then you can slowly decrease time needed to solve problem "A".

This is how I trained to get out of green zone.

Also, I noticed there is a fallacy that you may trapped into: no, no, problem "A" is very easy for me, I just made stupid mistake.

I had the same fallacy. Now, I think if you make even tiny mistakes then you are not on that level right now to solve this problem quickly. You should not hurry till you get 100% correct solution.

Also, don't try to write solution before you have clear understanding what to write.

I hope this will help you.

»
8 years ago, # |
Rev. 2   Vote: I like it +17 Vote: I do not like it

A general rule is: once you start coding, you stop thinking. I used to suffer from this a lot and still do now, to some extent.

Even when you think you have the solution, take a couple of minutes to go through it step by step until you have absolutely convinced yourself that it is correct. This also helps you figure out the simplest way to code the solution; you may think you are wasting time by not coding, but in the end, you will actually save time this way.

Also, try to only think about the problem and not about results. It's not easy to do, but important.

»
6 years ago, # |
  Vote: I like it 0 Vote: I do not like it

It would be nice to know how you improved yourself, assuming that you have become specialist on your own :p

  • »
    »
    6 years ago, # ^ |
    Rev. 2   Vote: I like it +1 Vote: I do not like it

    Being a specialist requires nothing. I don't see any improvement in myself. Still I do same types of mistakes mentioned here almost two years ago. Maybe the cause of color change is the typing speed.

»
6 years ago, # |
  Vote: I like it +7 Vote: I do not like it

One of my ACM teammate rarely gets WA even during practice sessions, I think he got less than 3 WA or TLE throughout 3 matches he competed in this season. (I averaged out around 3 WA/TLE per match on contrast :/ )

This is what he does — Adore his own code for 15 minutes before submission, and be aware of possible peformance improvements during implementation (He never uses untied cin/cout but scanf/printf, seldom uses recursion for dp but a for loop etc. ).

Although this is not doable in a short solo contest but you get the idea — Make sure you understand what your code is doing when you submit, instead of knowing what it should have done when you submit.