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 June 1st 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.

A week ago, I was sitting on a plane at Stansted, buffetted by hurricane winds and wondering when, if ever, I would arrive at my destination. By the end of that day, my carefully-planned segment of time for uploading the contest documents had dwindled to a few minutes before I had to leave the site where I had web access. Fortunately, that was just time enough. However everything was uploaded in one pile of documents.

I’ve now re-uploaded the contest documents in a directory structure that makes it more obvious that they are just the PDFs and editable versions of one document, one summary slidepack and one slidepack of examples.

The documents are the same as the ones uploaded a week ago except that I’ve taken the opportunity to correct a few missing brackets and commas, and to recast a couple of sentences that weren’t as clear as they might have been. I’ve also added a file of karyotype string examples for use in testing.

An Ethical Competition

A contestant emailed me a very reasonable question, which simply had not occurred to me when I was planning this contest: is there any likelihood of this application being used in a pre-natal screening scenario? The short answer is no. If anyone wants the detailed answer, just email me.

No, the title is not a reference to the condition you'll be in after reading through the contest documents. :-)

An interesting example was completed just this week (IIUC) of how the contest app might be used. There is a condition - droopy eyelids - which is of little trouble to adults who have it but which it is important to diagnose correctly in young children. The reason is that a child with it will fail to use their eyes sufficiently at a crucial early age when the brain is learning how to see.

(The following is my oversimplified summary.) A UK lab, using karyotype analysis, linked the condition to an abnormal 7 chromosome with an unreadable section. A transatlantic lab, by contrast, using Arrays and FISH, asserted it was a chromosome 1 abnormality. Through putting these results together at a joint conference, the full state has now become known.

• Sometime in the past, there occurred an insertion of material into chromosome 7 from chromosome 1.

• The abnormal chromosome 1 that resulted was not inherited by anyone. Thus the UK karyotype group was correct to report that patients with the condition were consistently normal, or not relevantly abnormal, in their chromosome 1s.

• The abnormal chromosome 7, with its added material from 1, was inherited, so the US group was correct to argue for some kind of 1 involvement.

Thanks to this work, in future, when parents or doctors observe seeing issues in an infant, they may be able to get an earlier and more certain diagnosis of whether it is or is not this condition, thus ensuring in time that the child is helped to see at the age when their brain needs to see for vision to function well in later life.

It would probably be a great exaggeration to say the contest app would have let these two groups reach the result much faster, but it might have helped a little.

The contest documents consist of PDF and editable (.doc, .ppt) versions of:

• STCodingComp - Admin and the Text Language: slides on what motivated this problem, followed by examples of inversion and translocation (with diagrams) and other operations. Use this to flick through the operations and their text forms (noting what I say below about the right way to grasp the problem).

• SmalltalkCodingComp2008: this contains the stuff on the contest admin and contest overview web pages, followed by domain overview, examples and definitions.

• STCodingComp - Karyotye examples: this has a few more karyotye examples. Just for interest, these are shown against pictures of what the user looking down the microscope sees. In a couple of cases, I note the kind of remarks the analyst might make as they view the real chromosomes; this gives you a domain feel for the abstract, schematic nature of the chromosome diagrams your web app will show.

• StandardKaryotype: .jpg and .bmp versions of this .gif of the normal chromosome band structure ideograms. You don't have to conform to this diagram's visual style at all; it is just one way of showing the data, and it shows the data you have to display.

• BandingPattern: .txt file of the structure shown in the StandardKaryotype diagram. The diagram omots a couple of 'obvious' labels for space reasons; the text file gives the complete list. (The information in this file is also here.)
  

• ExampleKaryotpesForTests: .txt file of strings to inspire visual tests or use as input.
  

(There are also .jpg and .bmp of the diagrams that illustrate insertion and translocation in STCodingComp - Admin and the Text Language.)

How to approach this problem

This is a standard impedance mismatch problem: people are trying to describe schematic diagrams in text.

1. If you overview the text language, then progress your web app and domain model, then revisit each bit of the text language as you are handling that kind of cut-and-paste in your web app and model, it will all seem straightforward.

1. If you try to become expert at writing perfect text language expressions before starting to model the domain, then you will be ramming yourself right into the impedance mismatch problem you are trying to solve.

So my advice on how to approach things FWIW is to do (1) not (2). The documents inevitably give several pages to all the nuts and bolts of the text language because that is what you don't already know and will eventually have to handle; don't let that guide your approach.

Latest Upload

The latest upload, done on May 9th, added the BandingPattern.txt file (the diagram labels were unclear in a couple of places; this makes it all clear). All else is unchanged (a typo in ExampleKaryotypesInTests was corrected but it was in the notes, not in the Karyotype strings).

Read the contest overview.

Download the contest documents to get all the details.

Schedule and admin details are here.

Any questions, just email me. I'll use this blog to post the answers if they are of general relevance.

Good Luck.

Niall Ross