Posts

Showing posts with the label ICFP

ICFP 2010 contest is a bust for me

The ICFP 2010 contest rules have been posted, and I am quite disappointed by this year's contest. This year's contest is difficult to describe. It's too clever by half, and it depends too much on time, and too much on repeated interaction with the organizer's servers. The conceit is that you're designing "car engines", and "fuel for car engines". A car engine is a directed graph with certain properties, and "fuel" is a directed graph with other properties that generates a set of coefficients that are fed to the engine. Layered on top of that is an encoding puzzle (you have to figure out how the engine and fuel directed graphs are encoded for submission to the IFCP servers.) Layered on top of that is an economy where you are encouraged to submit your own car engines and write optimal fuels for other people's car engines. There are benefits for finding better fuels for existing car designs. (You aren't provided the details of th...

ICFP 2009 contest final scores

Final scores are out, and my team Blue Iris scored 80 out of 328 in this year's ICFP contest. Not as good as last year, ah well. :-) Next year: More sleep! And here's a video of the contest results presentation from ICFP .

ICFP 2009 contest blog - Team Blue Iris

I just threw in the towel on the ICFP 2009 Programming Contest . The problem this year was a set of 4 sub-problems related to orbital mechanics, plus a virtual machine spec. The virtual machine was used to enable the problems to be specified exactly, without worrying about differences in the order of math operations. Implementing the virtual machine was easy and fun. Unfortunately, actually solving the final sub-problem required learning too much math and physics. I was able to solve problems 1 and 2, and make an entry for the lightning round. And I brute-forced a solution for problem 3. But now, 56 hours into the contest, I am giving up on problem 4. I can see the general outline of how to solve it, but it would take sharper tools than I have now. For example, I'd like a way of solving Lambert's equations, but I'm having trouble deriving the code on my own, and the best example I've found while searching the web is a 30-year-old NASA Space Shuttle Fortran program . Al...

Getting ready for ICFP 2008

The rules for this year's ICFP contest have just been posted. Although the actual problem won't be posted until Friday July 11th, the rules themselves are interesting: Your code will be run on a 1GB RAM 4GB swap 2GHz single-processor 32-bit AMD x86 Linux environment with no access to the Internet. You have to submit source code. You may optionally submit an executable as well (useful if for example you use a language that isn't one of the short list of languages provided by the contest organizers.) Teams are limited to 5 members or less. I have mixed feelings about these rules. The good news is: It should be possible for most interested parties to recreate the contest environment by using the contest-provided Live CD. A computer capable of running the contest could be purchased new for around $350. It seems that the focus will be on writing code in the language of the contestant's choice, rather than writing code in the language of the contest organizer's choice. T...