The contest is still five hours away from ending, but everybody but me has either had to go home or given up, so I’m going to pack it in in a few moments, too.
We’ve made a fair amount of progress on the Meet and Greet problem, and are close, but not close enough unfortunately, and working alone I just don’t feel up to trying to fix it up. We also apparently have some progress on the math of the Eccentric Meet and Greet, but I don’t know how much of that ever got into the code.
We submitted answers only for the Hohmann Transfer Orbit problem and we’re currently at 261 out of 315 on the scoreboard, which puts us at about the 20th precentile—not a very good showing. What went wrong?
It took us ages to get to this point, but we’ve finally scored some points. Scenarios 1001, 1002 and 1003 are working well now, though we’re still somewhat baffled by a mysterious problem with 1004. (Despite using what looks like a very reasonable thrust vector to widen our orbit, we instead descend and crash into the earth.)
Last night was fairly depressing; we were pretty close, but couldn’t quite get our algorithm correct in time for a lightning round submission. We were trying to use a standard Hohmann transfer orbit, but for whatever reason we were using our position to calculate when we should do the second burn, rather than the time, and were doing our second burn too late. It wasn’t hard to fix today, but we were just too tired last night to be able to make this minor change.
The problem seems like a good one this year, and even better, it’s playing to our strengths. Paul is a computational geometry kind of guy, and building a VM sounds like a fun thing to me.
Before leaving home this morning, I registered us (as “shitamachino”—once again the contest organizers are using ISO-8859-1 for names, so we can’t enter as 「下町の⊥」)
Everybody wandered in between about nine and eleven this morning, and since then we’ve figured out the details of the problem, worked out the general strategy of our program, started writing the overall structure of it, assigned various tasks to people, and installed some useful libraries, including Conal Elliott’s vector-space.
The team is a bit smaller this year, just four of us: Paul (who was also with us last year), Travis, Bryan and me. We had quite a few other people interested, but they all vanished when it came time actually to sign up. That’s a bit unfortunate, I feel, because there’s no limit on team size this year, but shou ga nai, as we say in Japanese.
Material has started to appear on the contest web site, including a FAQ. Little clues have been scattered about, but of course these lead you in no particular direction; generally the meaning of them only comes clear after you know the contest problem.
We at Starling are starting to gather up all of our friends and gear up for the 2009 ICFP Programming Contest. There’s interest from about a dozen people this year, so it looks as if we’ll have quite the three day party!
With this many people, even though we’re (almost) all functional programmers, we don’t share a common preferred language and platform. This, of course, has provoked discussion. I thought I’d put forward here some of the criteria you should consider when thinking about what languages to use as you approach the contest.
I’m at ICFP right now, listening to Tim Sheard’s presentation on the ICFP 2008 Programming Contest as I write this blog entry. The information about the contest development was moderately interesting. As we knew, the server was written in ML; there were also two sample clients, one in 800 lines of ML (sharing about 500 lines of the server) and one in about 1400 lines of Haskell. Writing the clients was quite helpful to understand better the problem, and in fact they simplified the problem in several ways based on this experience.
There are some interesting language stats; it appears that Python, C++, Haskell, and Ruby are getting more popular (compared to 2003), and C, Perl and Scheme are getting less popular.
I was having a look through the blogs and code of some of the other competitors and found a few things of interest.
Greg Heartsfield’s entry was done in Haskell and in many ways seemed similar to ours. (Well, the code wasn’t formatted nearly as nicely. :-)) He didn’t use Parsec for the parser, and comparing the two parsers, I think ours (which did use Parsec) is a bit cleaner. But he did use the State monad for control, whereas we threaded the state through by hand. (I really should look at that State monad one day.) We both seem to be doing similar geometry stuff, though our typed, vector-based calculations seem nicer. I didn’t see him in the first final trial, though; I would have been curious to compare his results.
Some results have been made available. The first few trials of the lightning round were made available first, which just rubbed in the annoyance of forgetting to submit for that, but a few days later we also got the first seven trials of the final round, and we didn’t do that badly at all. (You can find us listed as “shitamachi no ue”.)
Apparently several contestants failed the first trial due to problems connecting to the server. One cause that there was some noise about was being able to connect when given an IP address, but not when given a hostname. That must have been rather frustrating.