Posts

Showing posts with the label programming

My debugging and bug prevention strategies

Programmers, such as myself, frequently encounter bugs in our program code. Sometimes, we are able to resolve them quickly, sometimes it take hours. Worse still, after resolving the current set of bugs, another pops up! As a programmer, I have experienced the pain of debugging my program code, for hours on end, not knowing what is wrong with my logic. Over time, I have developed a debugging toolbox that has proven to be effective for myself. I have to mention though, that this only applies to Competitive Programming, not professional programming, where circumstances could vary greatly. Another point to note is, my discussion is more skewed towards C++ programmers so issues like segmentation fault may not apply to languages such as Java. The 5 most common bugs/errors that I have seen are (in no particular order): 1. Segmentation fault. 2. Integer overflow 3. Division by zero 4. Strange output values with multiple test cases 5. Logic Errors No. 1 is mostly easy to...

My direction in Competitive Programming

Having carefully-developed a well-tested template for programming contests, I am currently looking for ways and means to improve my speed and accuracy in contests. The latter can only be improved through more experience and faster typing speed. In order to fix my slow typing speed, I have learnt touch-typing - my typing speed has increased from an average of 40+wpm to 75 wpm ever since. My extensive list of programming macros also puts less emphasis on my typing speed. As for problem-solving speed, I have to admit that the author of "Competitive Programming" is right - use the simplest solution that works. Who cares if it is not the most efficient solution? What matters is the "accepted" status. Hence, I am now working in that direction - to write solutions that just make the cut and are easy to implement. An additional effort that I have made over the past year is to develop a well-documented code library of common data structures and algorithms that I would ne...

Efficient learning in Competitive Programming

Many competitive programmers (myself included) often face difficult problems that we cannot solve for days on end. This is normal because no one knows everything. But I feel that spending many hours trying to crack a single problem is a waste of time and stems learning. If we cannot solve a particular problem, it could probably be due to the lack of one or more specific skills and/or concepts. For example, how would a beginner programmer know how to use dynamic programming? He or she would not even know that the question requires dynamic programming. As a former beginner, I can emphatize with those sentiments. When I first embarked on my Competitive Programming journey, I could spend an entire day working on a single problem, which turned out to be very trivial after using a few simple tricks. As such, it is imperative to read editorials and other AC (accepted) solutions rather than trying to "challenge ourselves". Learning from others will help prevent us from reinventin...