The Humor Event Horizon
Where laughter becomes more hilarious than whatever half-forgotten thing preceded it.
Also known as H.E.H.
Where laughter becomes more hilarious than whatever half-forgotten thing preceded it.
Also known as H.E.H.
Konstantin Lopyrev writes (on the TopCoder forums):
“Everyone always discusses algorithms and such on this forum. However, there is one trait that is perhaps equally important as knowledge of algorithms – good problem solving strategy. By that I mean not jumping into solutions too quickly, thinking through everything before writing any code and such. Can anyone share what they’ve figured out that helps them? I’ve noticed that I have several flaws when I solve problems in general. I am too quick to start writing code. Also, I don’t think through my algorithms thoroughly. Also, there are many other things. Does anyone have similar flaws that they’ve already passed. If you have, please share your strategies for getting better at problem solving in general. Anything would be helpful, since I have the TCHS tournament coming up and I want to go home with some sort of prize.”
I wrote back, on May 10th ’07:
One thing I want to start doing is to make estimates of the implementation time of parts of my solution, how difficult each will be to code correctly/debug, and how sure I am that my method will work in the first place.
I’ve gotten very good at making estimates of time and space constraints. Now they are second nature. But knowing how best to solve a problem practically is still another area which I need to improve.
For example, for the last hard problem on TopCoder (circa May 9th, sorry, you’ll have to register to see it). I broke the problem down. Six steps toward victory! Five of those steps were really quite simple, though a few bugs crept in. The sixth was brutal — I could solve the problem by implementing a complicated comparison function object which recursively called itself on sorted sets of children. It was really crazy. To get it all working properly took nearly eight hours after the match.
Each bug, if not isolated, tends to increase debugging time by something like the square of the number of interacting components: the rate at which the number of dependencies would grow. Perhaps it would be simpler to either independently verify each component (by having pre-written tested functions or methods), or to organize the program, inasmuch as possible, as a linear pipeline or other simple acyclic graph. In fact, one might take a few seconds just to sketch the program idea out — how strongly coupled is it? What can I be sure of? How much of a pain will it be to debug? Can I make it less so? If not, can I anticipate debugging requirements and build in information gathering tools?
One morning around the graduate college dining hall, there was a gathering of physicists, finance students, and economists. The physicists are always quite amazed by those people who decide to forgo the life of the ivory tower, and choose to strike out into the real world, and so could not be kept from asking what the economists actually did. Furthermore, we could not be kept from wondering aloud what type of mathematical models they built and polished, and whether any of them had a physical interpretation.
One of the economists scratched his head, drew a sip of black coffee from his porcelain cup, and mumbled something about how a large proportion of the physics department of Harvard University was hired by a trading company, with the lure of riches beyond the pale of the meager imaginings of the physicists (“you mean I can afford a house?!”).