Блог пользователя rezaulhsagar

Автор rezaulhsagar, история, 8 лет назад, По-английски

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]

  • Проголосовать: нравится
  • +47
  • Проголосовать: не нравится

»
8 лет назад, # |
  Проголосовать: нравится +54 Проголосовать: не нравится

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 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

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 лет назад, # ^ |
      Проголосовать: нравится +1 Проголосовать: не нравится

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

»
8 лет назад, # |
  Проголосовать: нравится +3 Проголосовать: не нравится

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 лет назад, # |
Rev. 2   Проголосовать: нравится +27 Проголосовать: не нравится

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 лет назад, # |
Rev. 2   Проголосовать: нравится +17 Проголосовать: не нравится

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 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

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

  • »
    »
    6 лет назад, # ^ |
    Rev. 2   Проголосовать: нравится +1 Проголосовать: не нравится

    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 лет назад, # |
  Проголосовать: нравится +7 Проголосовать: не нравится

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.