Tornad0's blog

How to avoid bugs for A problems
By Tornad0, history, 8 years ago, In English

A problems are simple, and I tried to submit once without testing, but I always failed to accept at once. Sometimes I get stuck in very simple mistakes. I feel that programming is so hard because of those mistakes, so I even don't have confidence to think about harder problems with advanced algorithm. Any advice please? Maybe I should change from C to another language? （But sometimes I really enjoy graspping the idea of hard problems. There are so many difficulties and exceptions for me to communicate with my computer.）

  • Vote: I like it
  • 0
  • Vote: I do not like it

Comments Comments (6)
| Write comment?
»
5 years ago, # |
← Rev. 2   Vote: I like it +12 Vote: I do not like it

but I always failed to accept at once

That's because of inexperience. I used to get stupid bugs in the past. But after some practice, I got accustomed to the usual bugs that would occur in my code (like dividing by zero, integer overflow, off by one bugs, etc.). You just got to keep practicing. Spotting these trivial bugs will soon become second nature to you.

Anyway, (div 2) problem A usually don't have many corner cases (if any at all). The obvious things to look out for, though, would be extremely small input, extremely large input, empty sets, etc.

What I do though, is to read through my code once to see if it is intuitively correct. If it is clearly correct, I submit. Otherwise, I manually try a few cases. Worst case, if I am not confident of my solution, I would start writing a test case generator.

→ Reply
  • »
    »
    5 years ago, # ^ |
    ← Rev. 4   Vote: I like it -7 Vote: I do not like it

    How do you generate test cases through a code ?

    → Reply
    • »
      »
      »
      5 years ago, # ^ |
      ← Rev. 2   Vote: I like it 0 Vote: I do not like it

      Do I really have to teach you that? All you need to know is how to generate random numbers. That's all. The rest is just fitting the numbers to the problem constraints.

      In case you were asking about strategy for testing, I usually tweak the bounds between small and large to make sure that extreme cases are covered. Of course, I will make sure to manually enter some extreme cases by hand because those are unlikely to be generated automatically.

      → Reply
      • »
        »
        »
        »
        5 years ago, # ^ |
          Vote: I like it 0 Vote: I do not like it

        Yeah, we generate random numbers. But how do you know it always produces correct output?

        → Reply
        • »
          »
          »
          »
          »
          5 years ago, # ^ |
            Vote: I like it +5 Vote: I do not like it

          You write bruteforce solution as a checker.

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

          Well, you can almost always write a brute force program that searches the entire solution space. Although this program can not pass time limit, it is very unlikely to be wrong (unless you made some coding bug). Thus, you can be confident it will give you the correct answer to your test cases. If you are really paranoid, submit your brute force program, have it TLE (not WA). This should give you extra confidence in its correctness.

          → Reply