Having done a few programming competitions, I know firsthand how it's important when developing software solutions that the developer utilizes a sound approach. A lot of times a brute force approach will suffice, but issues arise when the software is put through the torture test of a large set of data.
In a university setting, Computer Science students are asked to come up with solutions for fairly trivial problems, at least in my experience. Coming up with the first 50 prime numbers isn't that challenging. Coming up with the first 500 or 5,000 might be more difficult. The first 50 primes might take seconds, if that. But try your code with an order of magnitude larger of a value and you might sit. With as powerful as even the cheapest machines are these days, sitting for more than 10 seconds, depending on your computation, might suggest that your approach is poorly designed or executed.
In my program, many of the projects are one-off assignments where the goal is to do X objective. Students have generally been punished, grade-wise, for uncommented code, but that has been the extent of the requirements in most cases. A brute force approach will work most times, but the code isn't well designed.
A possible solution to this is to treat the assignments more like those problems assigned at programming competitions: use a large, varied set of data when computations are being performed, and require a reasonable amount of time to finish the computation. Build a decent approach and your computation is done lickity split, but attempt to do things in a brute force manner and you just might sit and wait for seconds, minutes, or hours.
There are few things more satisfying in this discipline than coming up with a great solution for a problem that has given you fits. I've found a good resource in the Project Euler questions. Working on problems that require a good approach gets you thinking about how to keep your algorithms lean, and it'll help you know the limitations of the language you're working in (i.e. limitations with using integers vs. floats vs. longs, rounding errors, etc.)
This is a place where I share my thoughts on Software Development, learning, and my life experiences, among other things.
Thursday, November 10, 2011
TechPoint Innovation Summit Overview
Ball State had a series of booths at the TechPoint Innovation Summit to showcase some technologies and student-led projects. Morgan's Raid was featured, and I and another student involved in the game's development were there to answer any questions passerbys might have.
Overall, we received a lot of positive feedback. Those people who stopped were interested and impressed (or at least they pretended to be) with our work. Even the fellow Ball State-related individuals seemed impressed and could understand how much work went into it.
The crowd at the event was overwhelmingly business-folk, which was perfectly fine. Not everyone was interested in our work, which is understandable. I am, however, glad that I took some advice from someone and suited up. There were plenty of potential employers on-hand, and I would rather err on the side of business attire than on casual, but I'll talk more on potential employers in a moment.
My colleague and I didn't get a chance to hear many of the talks/presentations other than the one directly after lunch (speaking of lunch - it was fantastic!). We were pretty busy chatting with the folk that came by our booth.
As far as potential employers, there were the expected Indianapolis companies, Interactive Intelligence, ExactTarget, etc. Anacore had their Synthesis technology on-hand, and the demonstration was impressive. It looked very fluid, very easy to use.
There were plenty of other companies that my partner in crime and I spoke with, and I'm glad that I went. Even if I don't land a job from any of my leads, getting out there and speaking to professionals is a worthwhile experience. It definitely eased some of my anxieties, and I'm thankful to be entering into a field that appears to be very healthy, despite an uncertain business world.
Saturday, November 5, 2011
Whirlwind
It seems I have reached the point in the semester in which everything comes due and everything occurs. Hopefully I've navigated it well enough to get through this semester with all of my hair. Time will tell.
I never summed up my thoughts on the ACM programming competition, which shows how much I prepared for it: very little. I'm disappointed that my schedule ratcheted up from "slightly busy" to "incredibly busy" at seemingly the worst possible moment, but such is life.
The competition itself went decently. Our team performed acceptably, and I'm confident that the majority of our issues stemmed from all of us being plain-old too busy to prepare. The skill in these competitions is (quickly) seeing the mathematical question within the prompt paragraph(s). That and I/O. After the competition at Huntington University over a month ago, my team was pretty prepared for any potential I/O hiccups.
My teammates and I were not aware that we would not be using Eclipse. It wasn't an unreasonable request by the competition operators to not allow us to, we just hadn't read the fine print to see that we would be, basically, using notepad and compiling via command line. This isn't a difficult task, but by never having done it we were more than a little frazzled when we didn't see our most familiar IDE. After a quick "Hello World!" introduction to our software, we were back in business.
The questions for the competition were reasonably harder. The competition itself was interesting because every team received a balloon (balloons are the competitions "theme", if it were to have one) whenever they achieved a correct answer. By the midpoint of the competition, our team had no balloon (because we had no correct answers) which took a fun thing (receiving a balloon) and turned it into a sad, depressing thing. We managed to get a single correct answer and were in the process of getting another correct before the competition ended. Bummer, I still want my balloon! It's an interesting thing to provide a resource, make it scarce, and then see how people will be excited and motivated just by the idea of receiving that thing.
Overall, it was a lot of fun. I obviously wished I had invested a bit more time to prepare, but, if it wasn't blazingly clear: my life is quite busy. I would highly recommend any undergraduate student to take part in a similar event. It may not make you a better professional programmer, but they make you think critically about a problem. They force you to come up with a solution, which can expose some shortcomings in your own thought process. An example: I've been interested with the Sieve of Erastosthenes, which comes up with the number of primes up to a number n more elegantly a brute force approach. A problem (Question D of the pdf in the previous paragraph) during the competition required us to check a large set of numbers to see if they had a certain mathematical quality. Our group had a lot of back and forth discussion about whether we could compute a master list of numbers we would look for, and save them in an array or list. Then, we could check the input to see if the number was in our collection. A member of our team took the stance that it could not work. We talked it out, tried a different strategy, and then came back to my idea (it was one of the few good ones I had that day!) and voila! It worked! Our initial approach took far too long to compute the answer, so thinking of the Sieve helped me develop a better strategy. Sometimes you can get away with brute force, but some questions expose how poor of a choice that really is.
I wish I had another year to compete in these kinds of competitions, but, barring any catastrophic events, I'll be ineligible this May when I graduate. Darn!
I'm really looking forward to the spring, so I'm having trouble keeping my eye on the prize --- the prize being this semester as a whole ending well. Our group for the spring met at the Kitselman Center and discussed some preliminary ideas about what we want to work on. The center itself is a great old building. I was a little disappointed that it didn't have more wide-open spaces, large rooms that could accommodate the entire team easily. But my concerns melted away when I saw the attic! It's a large, open room that could easily hold all of us in a work environment. My jaw might have hit the floor when we walked in. I could easily see us modifying it and having a stellar studio setting, if we can successfully reserve the room. Exciting stuff, and I'm looking forward to wrapping up this semester and getting a chance to work with some great people!
I never summed up my thoughts on the ACM programming competition, which shows how much I prepared for it: very little. I'm disappointed that my schedule ratcheted up from "slightly busy" to "incredibly busy" at seemingly the worst possible moment, but such is life.
The competition itself went decently. Our team performed acceptably, and I'm confident that the majority of our issues stemmed from all of us being plain-old too busy to prepare. The skill in these competitions is (quickly) seeing the mathematical question within the prompt paragraph(s). That and I/O. After the competition at Huntington University over a month ago, my team was pretty prepared for any potential I/O hiccups.
My teammates and I were not aware that we would not be using Eclipse. It wasn't an unreasonable request by the competition operators to not allow us to, we just hadn't read the fine print to see that we would be, basically, using notepad and compiling via command line. This isn't a difficult task, but by never having done it we were more than a little frazzled when we didn't see our most familiar IDE. After a quick "Hello World!" introduction to our software, we were back in business.
The questions for the competition were reasonably harder. The competition itself was interesting because every team received a balloon (balloons are the competitions "theme", if it were to have one) whenever they achieved a correct answer. By the midpoint of the competition, our team had no balloon (because we had no correct answers) which took a fun thing (receiving a balloon) and turned it into a sad, depressing thing. We managed to get a single correct answer and were in the process of getting another correct before the competition ended. Bummer, I still want my balloon! It's an interesting thing to provide a resource, make it scarce, and then see how people will be excited and motivated just by the idea of receiving that thing.
Overall, it was a lot of fun. I obviously wished I had invested a bit more time to prepare, but, if it wasn't blazingly clear: my life is quite busy. I would highly recommend any undergraduate student to take part in a similar event. It may not make you a better professional programmer, but they make you think critically about a problem. They force you to come up with a solution, which can expose some shortcomings in your own thought process. An example: I've been interested with the Sieve of Erastosthenes, which comes up with the number of primes up to a number n more elegantly a brute force approach. A problem (Question D of the pdf in the previous paragraph) during the competition required us to check a large set of numbers to see if they had a certain mathematical quality. Our group had a lot of back and forth discussion about whether we could compute a master list of numbers we would look for, and save them in an array or list. Then, we could check the input to see if the number was in our collection. A member of our team took the stance that it could not work. We talked it out, tried a different strategy, and then came back to my idea (it was one of the few good ones I had that day!) and voila! It worked! Our initial approach took far too long to compute the answer, so thinking of the Sieve helped me develop a better strategy. Sometimes you can get away with brute force, but some questions expose how poor of a choice that really is.
I wish I had another year to compete in these kinds of competitions, but, barring any catastrophic events, I'll be ineligible this May when I graduate. Darn!
I'm really looking forward to the spring, so I'm having trouble keeping my eye on the prize --- the prize being this semester as a whole ending well. Our group for the spring met at the Kitselman Center and discussed some preliminary ideas about what we want to work on. The center itself is a great old building. I was a little disappointed that it didn't have more wide-open spaces, large rooms that could accommodate the entire team easily. But my concerns melted away when I saw the attic! It's a large, open room that could easily hold all of us in a work environment. My jaw might have hit the floor when we walked in. I could easily see us modifying it and having a stellar studio setting, if we can successfully reserve the room. Exciting stuff, and I'm looking forward to wrapping up this semester and getting a chance to work with some great people!
Subscribe to:
Posts (Atom)