Link to the write-up: http://psyho.gg/2015-challenge24-finals/
Sorry for making another blog on the same subject, but I already was a halfway through when ArtDitel posted his own. And, considering the amount of work I had put into it, I think it deserves its own post.
I went the hard way, and the write-up focuses on solving the actual problems, instead of bashing the organizers :)
Congratulations!! It is amazing all the great chances for experienced coders.
Thanks for write-up! I knew you would write solutions, so I preferred to bash organisers :)
I figured out that since I wrote it for M24 & D24, people would expect me to write another one :)
Sorry for unintentionally suggesting that your post only bashed the organizers :)
Keep writing them, it's really great for community (and me, of course :) ) to read winner's solutions. By the way, which taskset do you prefer: CH24 or M/D24?
Normally I prefer much more CH24 style. CH24 is closer to exploration of the problemset, while M24 & D24 is usually a pure competitive experience.
The big downside of M24/D24 is that, because we have exactly three problems, each teammate chooses one problem and there's very little cooperation inside the team. It's like joining scores from different people in individual contest to determine the final winner. In order to fully understand your teammates' problem, you need to spent a lot of time. This is an investment that usually doesn't pay off. In both of those contests I spent few hours trying to help my teammates, but in both situations I don't think it was worth it.
Challenge24 on the other hand requires a lot of effort in deciding the "who solves what" problem. Also, because not all of the tasks are games (and sometimes games are scheduled, so they don't need your constant attention — like Ping-Pong task this year), there is much more variety in the problem set. The dynamic of the contest also changes a lot. At the start, you're solving classic problems that usually can be considered as easy points. Then, you switch to games or very unusual tasks. In the end you focus on optimization tasks, since they don't lose their value over time. The tasks are also quite often more complex and it's easier to split them within the team.
That being said, it's really hard to tell since both M24 & D24 made huge leap forward in terms of quality of the problems. With D24 being slightly ahead (although that's my personal opinion). And CH24... you know :) Despite all of the flaws, I had similar amount of fun in both types of contests.
Have you tried ICFP contest by the way?
Ah, the famous contest :)
Yes, but only very briefly. I lazily participated in 2009 & 2010 during the lightning round. I believe those were some of the weaker contests ICFP had. At least that's what I assume, since I heard a lot of praise about the ICFP, but what I saw were some unnecessary complex problems which weren't really interesting.
One of the problems I have with ICFP is that it has a rather unusual schedule. It's too long for me, to be able to do it full-time. But it's too short in order to participate between the normal day-to-day activities. As far as I remember, there's no limit on the team size. Taking everything into account means, that I don't feel that everyone has the same chances for winning. I guess it's a minor thing for others :)
Anyway, you can sum my overly long answer as "Yes, but not seriously" :)
Thanks for the details!
I am working on starting up a 24 hour contest with a slightly different profile: no classical pure algo problems, but more hardware/image processing/sound/control/VM/exotic-languages problems. Sort of challenge24 finals without the algo problems.
After reading your post and remembering how much team work we had in our own competition team 6..10 years ago, I think I'd have only 2 large problems for the finals. The smaller of them would be around a hardware, the larger would be around some software simulation. I'd design a set of small tasks which would help teams to solve parts of the large tasks for a small amount of the score. This way different people could work on different small tasks but at the end all their results would be needed for the final (big score) solution, so essentially they need to work as a team during the whole time to be able to combine the parts.
(We did something similar in some of the challenge24 final tasks between 2010 and 2014 (for example the laser CNC task had a few introduction smallies on a simulator before teams would get to the actual hardware). However, since there were 10+ other tasks for such a final, I think there was only one guy playing with the laser in most teams. If there's only 2 large tasks and the solution of small problems have to be combined for the big score, that may be a different story.)
What's your opinion about such a setup? Do you think it would increase "team experience"?
I am working on starting up a 24 hour contest with a slightly different profile
Awesome! :)
no classical pure algo problems, but more hardware/image processing/sound/control/VM/exotic-languages problems
This sounds somewhat risky. One of the biggest problems with those various 24h contests is that we don't have any internet access. If something doesn't work, or the team lacks essential knowledge, they're screwed and they can't do anything. I think it should be important to have your "demographic" in mind. People from hackerspaces (hackers, CTF competitors, makers), algo guys (like most finalists of the CH24/D24/M24 now), students, 9-5 programmers, etc. Each group has a very different skill set. I'm bringing this up, because most people don't want to spend several days learning stuff before the contest. Especially, since they don't know if their knowledge is going to be useful at all. M24/D24 gets away with this, since they only use games over TCP/IP during the finals, and CH24 contains huge amount of problems where team can discard 1 or 2 if they don't feel comfortable with them. At least, that was the case in past years :)
For example, take the Sonar problem from the previous year. It's a great problem, but very few people would be able to actually solve it. It's fine if it's one of many tasks, but it's a bad choice when there are only few.
And a small comment about hardware tasks: While they are always great and fun to work with, the common problem with them is that they limit the number of tests you can perform. This is problematic because this means that the problem will have huge variance in the scores (and thus make the competition feel a bit random). This was the issue with the last 3 hardware tasks in CH24 (Ping-Pong, Ball, Laser).
I don't know your ideas, so my comments might be completely off :)
I'd design a set of small tasks which would help teams to solve parts of the large tasks for a small amount of the score. This way different people could work on different small tasks but at the end all their results would be needed for the final (big score) solution, so essentially they need to work as a team during the whole time to be able to combine the parts. (...) What's your opinion about such a setup? Do you think it would increase "team experience"?
I wholeheartedly agree. Having multiple subtasks based on the same theme (e.g. working with the same hardware), but from different domains (sound, games, vision, etc) is a great way for enforcing teamwork in a positive way. Probably having one very complex problem would be better than having a two.
However, since there were 10+ other tasks for such a final, I think there was only one guy playing with the laser in most teams.
I'm pretty sure that it wasn't the case, considering that each one of those four tasks was from a different domain. In our case, all 3 of us worked on it. One guy wrote the "program generator". The other one worked on origami (where he used the visualizer I wrote for him), and I worked on the remaining two (image + optimization).