Изменения рейтингов за последние раунды временно удалены. Скоро они будут возвращены. ×

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

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

Hi, I am sure we have all come across those problems that have these simple problem statements but are just diabolical to get right. Problems which give you moments like these

These problems are usually hard to get right for the following reasons:

  1. Corner test cases
  2. Tricky implementation

Typically problems which involve string manipulation, geometry or problems involving decimal precision are hard to get right in the first go without overlooking some minute details. Sometimes these problems require carefully breaking it up into cases.

Recently I solved the following problem and had 4 failed attempts before finally getting it right. In a competition, you might spend a ton of time trying to identify your bugs and that can make or break your final rank in the contest.

So here is what I want to ask the top programmers in the community -

Q. How do you approach such problems during live contests? I have seen many top programmers getting AC on such problems in the first try. (Usually their code is short, simple and consistent with the cases)

A. mkirsche Spend a lot of time thinking before starting to code, and don't take too many shortcuts (longer code is sometimes better if it's cleaner and easier for you to keep track of). I don't know what to tell you about precision — I have problems with that too.

A. Junior94 They're experienced, they've probably failed many times and know what works best and what doesn't.

Q. How do you test your code to ensure that you have not missed any corner test case?

A. Junior94 You can't know for sure if your code is 100 % correct until the final system testing but you can still write stress tests with brute force solutions.

Q. In case the implementation is long and taxing, what is your approach to keep the code neat and simple?

A. Junior94 Think before coding. Also usually the more time you spent thinking about the problem the better your solution will be (thinking in the right track of course). Experience helps a lot here.

Q. How much time do you invest in such problems before deciding they are too risky to solve in a live contest?

A. Junior94 Is the code going to be too long or complicated to write for the remaining time? Are there any easier looking problems remaining to solve? Is it too frustrating? There are a lot of questions you can ask yourself at this point but whether you keep working on it or move on it will be a risk you'll have to take.

Thanks!

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

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

Spend a lot of time thinking before starting to code, and don't take too many shortcuts (longer code is sometimes better if it's cleaner and easier for you to keep track of). I don't know what to tell you about precision — I have problems with that too.

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

    But for how long should one think? It has happened with me that I have spent a lot of time debugging some problem but then later realized that had I skipped it, I would have solved some other problem and scored more.

    Also if the solution gets long, doesn't it increase the probability of having silly bugs in your code?

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

I think only experience can help here. I'm definitely not a top programmer YET but here are my answers for your questions:

  1. They're experienced, they've probably failed many times and know what works best and what doesn't.

  2. You can't know for sure if your code is 100 % correct until the final system testing but you can still write stress tests with brute force solutions.

  3. Think before coding. Also usually the more time you spent thinking about the problem the better your solution will be (thinking in the right track of course). Experience helps a lot here.

  4. Is the code going to be too long or complicated to write for the remaining time? Are there any easier looking problems remaining to solve? Is it too frustrating? There are a lot of questions you can ask yourself at this point but whether you keep working on it or move on it will be a risk you'll have to take.

And most of the time in these type of situations you'll be making a trade off. And you'll only know if it pays off at the end of the contest. Honestly though, these questions could be answered like this:

  1. With enough practice you'll know.
  2. With enough practice you'll know.
  3. With enough practice you'll know.
  4. With enough practice you'll know. Also listen to your gut.