The ICFP contest starts in around two weeks and we are building a Common Lisp team again this year. TL;DR let me know if you want to be part of it.

For those that don't know, the ICFP Contest (https://research.microsoft.com/en-us/events/icfpcontest2013/) is a long running competition that poses a single hard, and sometimes mathematically deep, task for the participants to solve in a 3-day time period. The task is a secret which is revealed at the beginning of the contest. The problems are hard to solve, but (usually) easy to understand.

To give some idea of what kinds of problems you might expect, previous years have some awesome tasks like:

1. Designing control systems for a Mars rover2. Designing a flight system for orbiting satellites3. Writing an AI for a complex card game

At this time, we have 3 team members. If you are interested in spending a fun weekend participating, please let me know. Any Common Lisp programmers are invited to join this team, but ICFP is more geared towards people with a moderate to advanced understanding of programming and/or mathematics. People with a remedial understanding of both might not get a lot out of the experience, but don't let that stop you.

In order to get the collaborative tools set up and working properly, you will have to be an Emacs user and willing spend a half hour to hour setting things up over a video chat session. In addition, it is nice to have a few practice sessions under your belt before the actual competition. Also, due to the way the competition is organized this year, if you wish to have your name on the official team roster, you will have to get back to me relatively soon. So, please let me know if you are interested sooner rather than later.

This is a great chance to include a bit of a social element into your programming and to learn new techniques from other hackers. I hope to hear from you.

Well, we did alright in that we understood the problem and were able to get a working solution well before the end of the weekend. We had a simple (read slow) but working solver pretty early on Saturday morning and perhaps before (there was one team-member that went off and did his own thing). We didn't have an extremely good/smart/elegant solution and we probably won't be breaking into the top 100 ranking teams, but we'll see if/when they put out the full rankings.

Basically, we scored some points but left a bunch of points on the table when we ran out of time. As one of my teammates pointed out, it is a simple calculation that if you solved them as fast as you possibly could, the server would still limit your submission rate and it would take ~5 hours just to submit solutions to all of the problems that were initially assigned. We needed to be much less cautious much earlier. But even then, we couldn't compete with people scoring in the 500 range, let alone the top groups scoring in the 1400 range.

It looked like more than half of the participants didn't get one point so having solved something seemed like a win

As I read the assignment I noticed the rate limit and that the clock didn't start ticking until you did eval/guess so I thought they probably wanted the solution to do a both some precomputing, even memoization maybe, before doing requests. I bet the lightning division winners did something like that getting the number of requests/challenge very low.

To be honest, every problem we solved was a two request ordeal: one "/eval" to get 256 values spread over the domain and one "/guess" to submit a guess. You really can't get fewer requests than that. Whenever this failed, it was due to either our search mechanism failing to find the solution fast enough (in which case we abort) or an error being found in our \BV evaluator (still not sure where the bug was).

We had the code in place to refine with further eval requests, we just never needed it.