Andrew Birkett's blog

I’m fermenting two digital-camera inspired programming ideas at the moment. I saw a commercial program for digitizing whiteboards by photographing them and post-processing. The company charges something like $250, which is pretty steep for a 2d warp, some filtering and a bit of color quantization. So I’ve been working on my own version, written in ocaml.

The second idea is to do OCR using a digital camera instead of a scanner. Clearly, if it works then it’ll be cool because cameras are much faster than scanners. Normally, OCR programs only need to correct for rotation (if you scanned the page squint) before splitting the page up into characters and matching them. If you’re working from a photograph, you might have to correct for perspective and non-flat pages too. There’s very few open-source OCR packages out there, so that’ll be an impedement to getting started on this project.

Gee, just think of the digital shoplifting implications!

I was lying on the grass in Holyrood Park this evening, having returned to my hobby of finding new ways to fall off mountain bikes (by cycling backwards, or doing no-handed trackstands). The first thing I noticed was that I usually think of the sky as “that thing above the horizon”. That’s very two dimensional of me. When you’re lying on your back, the sky becomes this big circle all around you. I then spent a while trying to change my point of view from “I’m lying on the ground and the sky is above me” to something more like “I’m stuck to the earth by gravity and ‘up’ and ‘down’ are just convenient notation rather than being the whole truth”. And then I got onto software engineering ..

I am waiting for the ICFP programming contest to start. I’ve even managed to remember that we’re currently in BST, and the contest starts at 0:00 GMT. What posessed them to start a contest at this time? This is taking geek obsession with zero-based numbering schemes to new levels of stupidity.

Anyhow, I am using this contest to test Squeak “in the real world”. I’ve done lots of small-scale programming using Squeak recently, but now I want to see if it stands up to a 24 hour coding frenzy (I’m only entering the lighting division). So, first and foremost this is a Squeak coding exercise, and if I eventually submit an entry that’ll be a bonus. I wonder if they’d given bonus points if I managed to submit working entries in five different languages?

I’ve been playing around with recording my desktop with vncrec. I briefly thought about recording the whole of my ICFP effort so I could review it later. It’s really trippy watching yourself programming. You notice how inefficient current GUI’s are. I’ve just watched a recording of myself trying to click a small button, and it takes several attempts to get just the right position. The same problem occurs when positioning the insertion point before typing. No wonder Apple’s magically zooming application launcher is such a good thing for mouse users, and no wonder that I prefer to keep my hands on the keyboard. I don’t like the way that keyboard shortcuts in Squeak change their meaning depending on which window you’ve got highlighted. I’d like alt-B to always bring up a browser, regardless of where the pointer is.

On a seperate topic, I intend to later add a ‘autocomplete selector’ feature to the Inspector window. Since smalltalk is dynamically typed, you don’t really get the same sort of autocompletion which is available in IntelliJ or Visual Assist. However, if you’re entering code in an Inspector window, you do know what type ‘self’ is, so you can do better than the command-Q shortcut which just autocompletes using every single selector in the world. Most of the time, I’m typing “self foo” into Inspector windows, so it’ll be useful for me.

“If we spoke a different language, we would perceive a somewhat different world”. Quotations on Simplicity in Software Design.

“There is nothing permanent except change”.

Sigh.

A random “design pattern” which just popped into my head:

Imagine you have some large data structure which is expensive to update. Maybe it’s a list of integers and you want to clamp each element to be between 0 and 100. Normally, you’d go through each element, perform the check and update it if required.

Instead, I suggest keeping the original list and creating a seperate log of the ‘modifications’ which have been made to it. So now you have the original list and a note saying “by the way, when you read an element you also have to clamp it to the range 0-100”. Now you’ve made the update cheap, but accessing the data is more costly.

However, if your program is otherwise idle later on, it can come back and coalesce everything back down.

So you’re basically saving time in your “change it” code, paying it back a little at a time in the “access it” code, and you’ve got the option to pay off the debt entirely when you’ve got a bit of idle time spare.

Whether this is useful or not depends on the frequency and cost of updates and accesses. I’m noting it here as another potential “tool in the box” for algorithmic optimization. It probably lives next to memoization and similar such techniques.