I will point out that the number of questions solved always comes first. This is why Waterloo came in 2nd, with a massive collection of penalty points.
It is interesting, though, that even with all sorts of "planning" and "architecture" in the "Real World" (tm), software still manages to suffer under the "release date crunch" and turn into a horrible mess for the poor developers who follow. Anyways, there is a time and place for everything. With the contests, though, the code isn't necessarily "computers first, people second" unless you have the uncanny ability of being always correct on the first try. Probably half and half.
It is funny that you mentioned year-old code, because I actually recently had to dig some of it up (not for a contest, though). It didn't take me that long to figure out what I did. I used reasonable words like "above" and "below" to describe my arrays.
You are associating the ability to make up long names and design classes with good programming skill. Any fruitcake can make up long descriptive names for things, and designing objects isn't far behind that. But something has to make that object do something...
You seem to think (and actually, I see alot of people think) that this is some kind off hacking contest where because structured code is not necessary, we have some kind of real-time obfuscated code contest. I have little experience with what other teams write, but I can tell you that our team writes code which is well-structured (not object-oriented or anything, but somewhat modularized), with variable names which are sometimes a little terse, but important ones usually have mnemonically useful names. (Like q for a queue, or whatever). No asdf.
Performance is very important. An estimate of the upper bound for run-time is always made before we type any code in. If it isn't going to run in time, we aren't going to try that strategy. We plan our strategy for attacking a problem so that when it comes time to code, we know exactly what we need and where it goes.
Stability is also important. You KNOW that the judges are going to try to trip you up on null strings or disconnected graphs or other things, so you need to cover all sorts of obscure special cases.
You are describing an ACM team which has adopted some sort of probabilistic method of getting problems. I can assure you that if you submit a POS program with no indentation and no structure and all sorts of strange constructs all over the place, when it comes back incorrect, you will have the time of your life debugging it.
The ability to design reasonably structured debuggable code is crucial to doing well on these contests. I suppose reusability isn't that important. Nothing ever gets accomplished by hacking away as soon as you have some faint idea of how to solve a problem. It is inevitably harder than you think it is if you are not careful this way. Comments are sometimes added too, but I suppose not verbosely. We don't explain what a for loop does, for example.
I should say that when we solve contest problems in practice, often we can print out our solution with minimal clean-up and use it as a reference solution to the problem for the real contest.
Is this the WRONG way or the RIGHT way? I suspect that this is somewhere in between. At any rate, we are certainly not training ourselves to be spaghetti coders. If we used your outlined "RIGHT way" strategy, I'm sure our team would be trying to hitchhike our way back to Waterloo from Orlando right now!
I got the impression from the Orlando Sentinel yesterday that there were only two teams at the competition, St. Petersburg and UCF. I'm not bitter about the fact that Waterloo wasn't mentioned as coming in 2nd, but just that the local bias is on par with our school paper, the Imprint.
Anyways, enough ranting. I feel sorry for the UCF team because of the local news station which decided to camp out behind you guys during the actual contest and poke their cameras right into your faces while you were trying to work. Or that's at least what it looked like from our end.
Yes, it is a shame that American football seems to determine a school's worth in the US, unless you happen to be a big-name school like MIT or Berkeley. In a way though, doing well in the contest has put some small schools on the map in the CS world. I wish the UCF programming team continued success in the future.
Wow, I didn't realize that people cared enough about what I did to correlate things like that. I guess I should be flattered...:)
There is certainly a huge component to doing well in these programming contests which is based in a good background in problem solving (in particular mathematical problem solving), and there is a very good correlation between people who do well in math competitions and computer contests.
I'm sorry to inform you, though, that I am not a CS major, and that I am a C&O major, but I've taken a number of CS courses. The other Waterloo team members are in CS, though, and despite recent funding cutbacks and other assorted administrative knuckleballs, I still think that Waterloo has a very strong CS program. Sadly, I feel that there are people who would like to see less mathematical content (e.g. removing multivariable calculus from the requirements) and more "vocational training" in the CS program. I always felt that the co-op program gave our CS students enough vocational training for a well-balanced program whose graduates are thinkers and problem solvers, rather than simple code monkeys, but I feel that the demand for code monkeys and the agenda of the provincial government (who is holding the purse-strings hostage) is hurting our CS program to the point where we may not be able to brag about our "mathematically-based CS program" for much longer. It is important that people see the value in doing things from a theoretical viewpoint as well as gaining practical experience.
I feel that the thing to do is not to be bitter. There were teams which, like your own, solved problem F very quickly realizing that it was an easier problem, only to have "Wrong Answer" shot back. However, a few teams eventually deduced what was going on and fixed the problem. You can disagree (as I do) with how the problem was judged, but in the end, being bitter solves nothing. I certainly think teams which deduced the problem with the testing data deserve to have problem F under their belt. (I am not being biased by the fact that Waterloo was one of these teams.) Some school suggested afterwards that the entire question be struck from the contest and not considered at all. This is no solution.
There is nothing that can be altered with the competition results that is fair to everyone. Any team which has endured a regional contest where large mistakes are made realize that sometimes bad things happen to good people and that dealing with these issues is a part of the competition.
The lack of admission of error and the secrecy of the datasets is standard practice. I think every team should be prepared for this possibility. Anyways, having looked at some old regional competitions, I see a few instances where even the sample data given in the problem is incorrect. I hate to say that this is part of the game, because in a fair world, it is not, but the world is even less fair than the competition.
Most teams would rather use command-line tools rather than an IDE like Delphi or Visual Whatever. After that, you can develop quickly with just about any reasonable language. Not screwing yourself with pointers comes with practice. Our team (Waterloo) uses C as a language, and vi as our editor. (We were allowed to use a DOS version of vim.) I know that a few teams like to use Pascal, but there are not too many of those. Some teams like Java too. The majority use C or C++.
Slashdot Mirror
Hyperbole noted.
I will point out that the number of questions solved always comes first. This is why Waterloo came in 2nd, with a massive collection of penalty points.
It is interesting, though, that even with all sorts of "planning" and "architecture" in the "Real World" (tm), software still manages to suffer under the "release date crunch" and turn into a horrible mess for the poor developers who follow. Anyways, there is a time and place for everything. With the contests, though, the code isn't necessarily "computers first, people second" unless you have the uncanny ability of being always correct on the first try. Probably half and half.
It is funny that you mentioned year-old code, because I actually recently had to dig some of it up (not for a contest, though). It didn't take me that long to figure out what I did. I used reasonable words like "above" and "below" to describe my arrays.
Donny
You are associating the ability to make up long names and design classes with good programming skill. Any fruitcake can make up long descriptive names for things, and designing objects isn't far behind that. But something has to make that object do something...
You seem to think (and actually, I see alot of people think) that this is some kind off hacking contest where because structured code is not necessary, we have some kind of real-time obfuscated code contest. I have little experience with what other teams write, but I can tell you that our team writes code which is well-structured (not object-oriented or anything, but somewhat modularized), with variable names which are sometimes a little terse, but important ones usually have mnemonically useful names. (Like q for a queue, or whatever). No asdf.
Performance is very important. An estimate of the upper bound for run-time is always made before we type any code in. If it isn't going to run in time, we aren't going to try that strategy. We plan our strategy for attacking a problem so that when it comes time to code, we know exactly what we need and where it goes.
Stability is also important. You KNOW that the judges are going to try to trip you up on null strings or disconnected graphs or other things, so you need to cover all sorts of obscure special cases.
You are describing an ACM team which has adopted some sort of probabilistic method of getting problems. I can assure you that if you submit a POS program with no indentation and no structure and all sorts of strange constructs all over the place, when it comes back incorrect, you will have the time of your life debugging it.
The ability to design reasonably structured debuggable code is crucial to doing well on these contests. I suppose reusability isn't that important. Nothing ever gets accomplished by hacking away as soon as you have some faint idea of how to solve a problem. It is inevitably harder than you think it is if you are not careful this way. Comments are sometimes added too, but I suppose not verbosely. We don't explain what a for loop does, for example.
I should say that when we solve contest problems in practice, often we can print out our solution with minimal clean-up and use it as a reference solution to the problem for the real contest.
Is this the WRONG way or the RIGHT way? I suspect that this is somewhere in between. At any rate, we are certainly not training ourselves to be spaghetti coders. If we used your outlined "RIGHT way" strategy, I'm sure our team would be trying to hitchhike our way back to Waterloo from Orlando right now!
Donny
It happened in 1998 (or so). I think there are people thinking of removing STAT 231 from the list as well... Donny
I got the impression from the Orlando Sentinel yesterday that there were only two teams at the competition, St. Petersburg and UCF. I'm not bitter about the fact that Waterloo wasn't mentioned as coming in 2nd, but just that the local bias is on par with our school paper, the Imprint.
Anyways, enough ranting. I feel sorry for the UCF team because of the local news station which decided to camp out behind you guys during the actual contest and poke their cameras right into your faces while you were trying to work. Or that's at least what it looked like from our end.
Yes, it is a shame that American football seems to determine a school's worth in the US, unless you happen to be a big-name school like MIT or Berkeley. In a way though, doing well in the contest has put some small schools on the map in the CS world. I wish the UCF programming team continued success in the future.
Donny
Wow, I didn't realize that people cared enough about what I did to correlate things like that. I guess I should be flattered... :)
There is certainly a huge component to doing well in these programming contests which is based in a good background in problem solving (in particular mathematical problem solving), and there is a very good correlation between people who do well in math competitions and computer contests.
I'm sorry to inform you, though, that I am not a CS major, and that I am a C&O major, but I've taken a number of CS courses. The other Waterloo team members are in CS, though, and despite recent funding cutbacks and other assorted administrative knuckleballs, I still think that Waterloo has a very strong CS program. Sadly, I feel that there are people who would like to see less mathematical content (e.g. removing multivariable calculus from the requirements) and more "vocational training" in the CS program. I always felt that the co-op program gave our CS students enough vocational training for a well-balanced program whose graduates are thinkers and problem solvers, rather than simple code monkeys, but I feel that the demand for code monkeys and the agenda of the provincial government (who is holding the purse-strings hostage) is hurting our CS program to the point where we may not be able to brag about our "mathematically-based CS program" for much longer. It is important that people see the value in doing things from a theoretical viewpoint as well as gaining practical experience.
Donny
I feel that the thing to do is not to be bitter. There were teams which, like your own, solved problem F very quickly realizing that it was an easier problem, only to have "Wrong Answer" shot back. However, a few teams eventually deduced what was going on and fixed the problem. You can disagree (as I do) with how the problem was judged, but in the end, being bitter solves nothing. I certainly think teams which deduced the problem with the testing data deserve to have problem F under their belt. (I am not being biased by the fact that Waterloo was one of these teams.) Some school suggested afterwards that the entire question be struck from the contest and not considered at all. This is no solution.
There is nothing that can be altered with the competition results that is fair to everyone. Any team which has endured a regional contest where large mistakes are made realize that sometimes bad things happen to good people and that dealing with these issues is a part of the competition.
The lack of admission of error and the secrecy of the datasets is standard practice. I think every team should be prepared for this possibility. Anyways, having looked at some old regional competitions, I see a few instances where even the sample data given in the problem is incorrect. I hate to say that this is part of the game, because in a fair world, it is not, but the world is even less fair than the competition.
Donny
Well the next time you see me you should introduce yourself.
:)
Please stop stalking me...
Donny
Most teams would rather use command-line tools rather than an IDE like Delphi or Visual Whatever. After that, you can develop quickly with just about any reasonable language. Not screwing yourself with pointers comes with practice. Our team (Waterloo) uses C as a language, and vi as our editor. (We were allowed to use a DOS version of vim.) I know that a few teams like to use Pascal, but there are not too many of those. Some teams like Java too. The majority use C or C++.
Donny