Team Past Journal WriteUp Downloads

Competition Writeup

(Tapani's version)

This writeup assumes the reader is familiar with the 2007 task.

Day 1

The first day was spent on getting the basic tools working. One trick we used to get a working DNA to RNA compiler working was to let two persons to implement it and debug them by comparing outputs. Once both agreed, they were both assumed correct.

This turned out to be an effective way to get it working, so we did not discover the codes that enables sunlight over the scene until day two. :-(

For the lightning competition we opted for a strategy of describing the scene by filled rectangles of various sizes. While this gave around 1/3 of the pixels, we were easily beaten by all the teams who were skilled enough having discovered that 28 byte sequence enabling sunligt in the scene.

Day 2

After seeing the leaderboard we realize there is something we have missed. While we eventually found the magic sequence, the feeling that we are playing catch-up, lasted the rest of the competition.

The C++ version of the DNA2RNA converter was rewritten using STL ropes for improved performance.

We spend the day exploring the DNA, and learning how to call the functions inside DNA.

Day 3

Functions inside DNA was used to produce a solution image from scratch (even if some team members would have preferred to modify the default sunny source image instead). Parts of the submitted prefix was recorded as RNA from the sunlight image (like the anticompressant) and then compressed using DNA.

Also, it was a tough call to decide on when to stop exploring, and starting producing a solution. With hindsight, we should have done that earlier, and focused 100% on the approach chosen.

Lessons learned

Parallell implementations can be an excellent way to get complicated software correct (especially in cases where testing is limited).

Competing from two locations (Cadence in Berkeley and Chalmers in Göteborg) reduces the effectivity and focus of the team by the lack of communication.

A personal lesson of mine is that I should have a lower threshold when to abandon a poor tool and write a better one. While I wrote maybe 5-10 programs for various purposes, they should have been even more.


Page updated 25th July 2007