STIC 2008 Coding Contest

The second round of the 2008 coding contest took place in Reno exactly a week ago. Congratulations to Martin McClure, who headed the field, to Peter Hugosson-Miller who ran him a close race, and to the other three contestants. A beaming Martin could be seen later with his iPod Touch at the Instantiations wine and cheese party, wheedling John McIntosh for the Squeak VM that runs on it. Martin's wife was also delighted; previously, the family had owned only one iPod, which was won by her in an Adobe promotion but which was frequently to be found in Martin's hands. :-)

The first round is over, and I’ve enjoyed dialing up superhuman genomes and mutations worthy of science fiction while assessing it. However there is an unfortunate degree of overlap between people who attempted the first round and people who are not attending Smalltalk Solutions this year. I had raised the possibility of some remote participation in my contest spec but when the results were in there was concern on the STIC board about how very undramatic the spectacle might be of the extremely virtual second round that the audience in Reno seemed set to see (or rather, not see :-).

After discussion, we have therefore rejigged things. We now have distinct first and second round competitions.

• Rajesh is the winner of the first round, and with luck the up to circa $1000 reduction in his costs for attending Smalltalk Solutions next year that he has won will give us a chance of seeing him then. Well done, Rajesh!
  

• The second round is now open to everyone who attends Smalltalk Solutions. If you arrive early enough, you can start at 14:30 on Wednesday. If you arrive later, you can start the moment you reach the contest room. The coding ends at 18:30.

Good luck.

Less than 24 hours to go. Submission upload instructions are

• anonymous ftp to www.stic.st.
• cd to subdirectory coding-contest
• upload a zip archive (call it YourNameStS2008CodingContest.zip or similar) with your image, etc. (and if you have not already emailed me, please include an email)

Any problems uploading, email me.

Update, Saturday 17:45
The STIC firewall configuration is impeding some people from uploading.  If you are affected (and I have not already been in touch), email me (my email is my initials, which are n, f and r, at bigwig.net), and we'll arrange a means of submitting.

In a moment of mental abberation, I wrote in the post two below that the submission date was postponed from Friday May 30th to Saturday June 1st.  It is now corrected to Saturday May 31st, which is what I meant (as everyone correctly guessed).

I've added a list of all the Karyotype bands to the contest documents (see this post for the full list).  I've also put the information on this web page.  The list is easier to use than the diagram for some purposes.

When I announced this contest, I set the submission time for Friday May 30th. However Saturday would be easier for some people. So I've agreed to extend the submission time. Official submission time now closes on Saturday May 31st at 18:00 UK time.

I'll post specific submission instructions nearer the time. Generally, you can submit by doing either of:

• uploading the code to me with sufficient instructions that I can start a localhost site without too much difficulty

• having your site running (e.g. on seasidehosting.st or under GLASS or wherever) by the deadline, in which case I will also want the code to browse but will allow you a little extra time to get it to me and will not complain if I have to iterate with you to get it running locally

The final will be on the afternoon of Wednesday June 18th. I'm aiming for 14:30 - 18:30 but I'll agree the exact start time with the finalists when I know who they are. If a finalist cannot reach Reno by then (or cannot attend at all) I'll try to arrange their remote participation.

When emailing me questions, include 'smalltalk' in the text to ensure no over-eager spam filter blocks it. Having 'coding contest' in the title is helpful too.

To those already well into the task, good luck. To anyone thinking of doing it in the style of past years' coding contests - a concentrated two-week bash of weekends and evenings instead of the occasional slow-and-steady I've offered this year - you still have time but should definitely be starting to think about it.

I thought I'd move these answers to competitor questions from comments to a post.

1. Can we come up with our own textual representation/grammar?
A) This could be an eXtreme Programming 'first make it run, then make it right' approach: start with the simplest language that can possibly work and evolve it to the requirement as you go, simplifying or altering any parts of the standard text form you find hard to code, or hard to understand, when you first meet them.

What I'm thinking is that the language you start with is actually rather like the standard form but with your choices for any parts that are not easy to generate or are not immediately clear to understand: doing the task will make things clear, so generating standard text output (and input) will be easier in retrospect.  It could be a fast later / final stage to tweak your parser to reading and writing the specified text language, because:

• solving the problem for your chosen text form might make it easy to grasp how the specified standard addresses the same issues

• having running code, objects and visuals to look at would also make it easier

When the app is delivered, a requirement is that the user has to be able to generate a text string in the standard form from their input state. They must also be able to enter a text expression in standard form and see it in the app. An otherwise impressive app that was not perfect in its generation could still be a contender, but only if I think the imperfections are fixable by the finalist between submission and final, so you need to be a good first approximation.

However if you find making your own choices for bits of the grammar helps you make progress, by all means start that way.

B) This could be a great way to handle the fact that I am your customer and I am only available via email (and not always same-day response either :-). Start by being your own customer for the text part and treat me as the customer later, e.g. when you have a good grasp of the domain, 90%+ of your generated text looks OK, and you just need to understand what the text standard wants for some particular case.

C)  You may find yourself thinking that your language is (would be) more expressive overall, not just a coding speedup trick. I'm no advocate for the standard form; the problem exists because it is a poor way to describe these state.  That is largely because text is a poor form for describing visual information, but I have no warrant to claim the existing standard is the best possible. That said, be aware:

• at the end of the task, your app must be able to generate standard form output at some stage in its process

• you will be a much better judge of what is good or bad text for this after you have made progress on the app

So if you do this, I suggest you see it simply as an XP-style 'make it run, then make it right' approach and form your opinion about which grammar is better at the end.

D) My suggested approach in the main post:

• generate the individual expressions as you implement those operations in the app

• don't try to become an expert on the whole specified language before starting

is also XP-style: build a simple app that can handle insertions, then add translocations, then add balance/unbalance, weird stuff, and generate the increasingly complex text fragments as you go.

2. Do we start out with *the* standard normal chromosome state (i.e. the universal pattern of bands/subbands for humans), or can we assume our own 'normal' state?
The delivered app must be able to start from the standard banding pattern.

• The ability to accomodate different standard banding patterns, which future research may require, is a definite bonus (mentioned in my marking notes).

• The ability to start from an abnormal state, so recording a change relative to that state instead of to the standard start point, could also be a bonus. I didn't mention this in my notes; it would not be a significant point. There is a research use of exploring the multiple stages by which a very complex state might be reached. It might be natural to code your app with the start point as a configuration that you could then replace with any other you had entered. It might; and there again, it might not. I'm very happy to get this feature. It would not score major bonus points.

Hope this helps. Good luck.

Finalists in the coding contest count as speakers for attending Smalltalk Solutions. The supremely confident can register as speakers now. For everyone else, register normally; if you make the final, you will get the difference back at the conference.