03.27.08
Youtube is archive footage liberated
Great Physics mash up…
And a lovely Horizon episode on Richard Feynman – back when Horizon was worth shit. (courtesy of BadScience)
03.26.08
Parallel Human Computa
The original word for computer refers to “one who computes”. It was once common to have rows of human computers in military roles – people (predominantly women) who calculated missile trajectories. The term computer perhaps originated in one who crunched astronomical data and from the very beginning represented a task which was tedious and repetitive.
I was amused and intrigued a year or two ago with a Google talk regarding the idea of harnessing human computing time to help solve problems which mechanical computers still have no general solutions.
http://video.google.com/videoplay?docid=-8246463980976635143&q=google+tech+talks
While I was university in the late nighties, the vision and AI course lecturers were still quite optimistic about the progress of computers emulating human like tasks, but I quipped “yes, but in the 50s we were promised rocket packs and robots serving us toast in bed and I’m still waiting for my commuter grade rocket pack and robo Eggs Benedict”.
As computers and robotics became more advanced it became apparent that computers could excel on tasks heavily associated with intelligence (chess), but engineers found it hard to automate the laborious tasks such as ironing, cooking and mopping.
To this day, we keep expecting Moore’s law to enable computers to excel at tasks that humans are particularly well evolved for. Visual systems need a whole bunch of a priori knowledge about the world in order to determine the correct tags to label and categorise an image. Image labeling algorithms tend to be very poor compared to a human tagger, but the cost of hiring staff to identify images makes automation necessary. Most of us are unwilling to dedicate our time to such a mundane and unrewarding activity.
But, Luis von Ahn notes in the google talk that 9 billion human hours of solitaire were played in 2003, where as the Panama canal took 20 million man hours to construct (or 1 day of solitaire hours). He stresses that the economy of scales means that a small amount of time spent by a millions of users worldwide can create potential for real work.
It’s like stealing a penny from everyone’s bank account – the cost to the individual is small, but given enough people, it represents a small fortune.
Things have moved on somewhat, and google tried von Ahn’s method for Google Image Labeler which is still in perpetual beta. I wonder how successful it really was for them. I can imagine a sharp decline after a month or two as the novelty wears off.
A now famous example of tapping into human computer time, is the recaptcha.
reCapcha is a web site security tool which presents a fairly regular looking captcha. Rather than deforming generated words, it presents words which failed to be recognised by a book scanning program (OCR). By presenting text which by its nature vexes a machine , an active website utilising the recaptcha technology can help digitise the worlds printed material by harnessing the otherwise wasted time on regular captchas.
This obviously has the added benefit of feeling like a community service and is therefore feels less exploitative.
And this one:
Details of the project can be found at http://www.whiteglovetracking.com/
“On May 4th, 2007, we asked internet users to help isolate Michael Jackson’s white glove in all 10,060 frames of his nationally televised landmark performance of Billy Jean. 72 hours later 125,000 gloves had been located”
The data collected was not very sophisticated, contributors were simply ask to put a bounding box around the glove. But the response generated a processing speed of 1,736 frames per hour. Unlike the von Ahn’s method which to some may seem subversive and The Matrix-like, the glove tracking was assisted by willing participants and the data released to the public domain so that videos like the one above could be created derived from the data.
The original data are represented in the following video:
The question is, with millions of bored commuters with mobile phones at bus stops and in GP waiting rooms. What problems could be solved for both science and entertainment value with this formidable network? How can we harness the billion Snake-hours a year spent on Nokia phones.
Off the top of my head, a good example would be a guess that tune game, where consumers are played a short extract from a music track and asked to name the tune. The extract of the tune could have originated from a service such as Shazam.
Unlike the desktop, there are more likely to be people with headphones roaming around bored wanting to play a game.
Though I’m doubtful that any sustainable programme will materialise on mobile, It’s certainly a lot of fun coming up with potential ideas.
Please Note that this is different to using free CPU time, as in the Folding@home protein folding network.
03.24.08
Why I like python
For reasons I’m not going to divulge, I needed a timer that beeped every 2 mins to remind me to take a measurement.
I had a program running in 3 mins.
import winsound
import timewhile True:
winsound.Beep(2000,200)
time.sleep(120)
Thanks to single use, throw away programs; my life has become so much better.
When I have data in a form that’s difficult to work with, I think nothing of writing a script to transform it. If I have a repetative task which I’ve performed at least three times, I’m always looking for ways of automating it.
I use the python interpreter as my calculator now. With a few stock stats routines, it’s easy to crunch some data from the interpreter prompt. (iPython makes it even more of a pleasure http://www.scipy.org/).
It’s very liberating to take charge of data and program with a tools which just seems so intuitive and expressive. It reminds me why I got into programming. Because computers are supposed to make our lifes easier.
03.21.08
Resp…..onse time
I read the paper “Miller, R. B. (1968). Response time in man-computer conversational transactions.” in my first year university.
The basic advice regarding s/w response times has been about the same for forty years.
- 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
- 1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
- 10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect
When I was a product manager at Symbian, I would use these values to offer engineers a guide as to pefromance of software. (often there were no explicit peformance specifications).
Mobile phones and other consumer electronics fall are particularly sensitive to the reponse time contraints. It’s very frustrating to use a TV remote control with a half second lag.
Mobile phones tend to command our attention so that when playing with one, a time lag appears long since the user is staring at the screen, waiting for something to happen.
So, bear these values in mind when designing a system. And remember, give engineers a problem to solve and they will find a way – so long as you make it a high priority requirement.
Donald Knuth confronted a slow startup time of TeX with a novel solution – he launched the program to a startup state and then took a core dump of the application process and used an utilit which would reanimate the coredump, thus avoiding the startup code completely! Smart.
03.20.08
2 Unlimited
“Dual-use is a term often used in politics and diplomacy to refer to technology which can be used for both peaceful and military aims.”
I watched a very interesting talk by Bruce Schneier regarding Dual Use technolgies. It can be found here.
Obviously the internet is a great example of a dual use technology. Originally developed to de-centeralise military communications, it has found a place in the hands of civillians. To the point (as Bruce mentions), that the military basically has its own internal IP network which borrows from the lessons learnt on security in the public network.
A military worker, who plugs his work laptop in at home via VPNs, is vulnerable to virus which can spread into the internal military network. And as a result the commoditisation of software, or to put it another way – the net flow of civilian technology flowing back into the military is a new trend.
Military (and aviation) s/w has to have a high degree of quality in their construction and verification. A malfunctioning plane, or remote nuclear detonator can cost lives where as excel crashing (but allowing you to recover your data) is rarely critical.
The talk really got me thinking about the quality assurance problems that are presented to mobile handset manufacturers.
If avionic grade quality and security controls were applied to mobile software, then it’s likely that we would get one handset every two years from the major manufacturers.
That’s not to say that all phones are inherently flawed, it’s just that packing more and more features into a phone creates an environment which has more in common with desktop PC rather than world where mobiles come from – the signalling stack.
Mobile phone signalling stacks have to go through rigorous type approval, performance and network interoperability testing across several world regions. Although it’s hard to fully test the code paths in a signalling stack, code coverage of a ROM image can be assessed by hardware tracing the program counter. 3G Network simulators can be purchased for a quarter of a million pounds a piece and the software is verified for worst case latency and real time guarantees.
In other words, the characteristics of the signalling stacks are pretty much a known quality.
Many mobile phones in the last decade have built upon the real time OS used by the signalling stick by creating an application framework which sits in a lower priority thread.
This worked very well for simple phones – it was possible to have a snappy UI which handled the simple tasks such as dialling, address book and texting.
Since the UI ran in the same address space as the kernel, the characteristics of the UI had to be proven just like the rest of the stack.
One important aspect of real-time/embedded programming is that the memory requirements of an applications should be defined in advance. This means pre-allocating areas of memory for the applications so that they will always be able to run (no out of memory dialogs).
The result of taking signal stack mentality to apps was that limits were set across applications. A handset could have say 10 slots for incoming SMS messages and if the slots were filled up then the user would have to delete the messages to receive more (a waiting message alert indicated this).
By establishing limits, not only did the engineers have a spec to work to – but actually, users are more comfortable with limits than many people credited.
So while engineers can optimise the contacts database to 200 entries, allowing a 0.1 second search and open time, users get a better deal because they get snappier performing phones which seldom crashed.
The other interesting factor is that, when you have limits you can present very specific dialogs to the user. If you have run out of SMS slots, then the dialogs can say “delete some messages”.
On a smart phone, running out of space for SMS is often generalised as a “Low disk” notification where by the user can delete anything from a few contacts to a photo to free up enough disk space to receive a message (not all users are fluent enough in technology to realise that deleting a music track saves more space than a SMS).
Allowing apps to run in the background means that battery can be zapped, or starve another app of memory so that an application which worked ok this morning, fails in the afternoon.
Not only are smart phones technically very difficult to verify in terms of quality and performance, but the limitless applications makes it very hard to provide good information to the casual user.
I find it quite unfortunate that a lot of the techniques and idioms which made mobile phones so easy to use and reliable are starting to fade and their importance de-emphasised.
(It’s interesting that Apple have really applied consumer electronics dogmas very heavily to their iPods and iPhones and have received plenty of press coverage for their almost iconoclastic attitude to the “precious developers”.)
03.06.08
I didn’t join this team for the pay
Many discussions about staff benefits at work reminded me of this sketch from the marvellous Big Train.
Note: This video contains references to onanism.
03.05.08
Symbian Text shell
I frequently write test code which executes in a “text shell” test harness. This is the Symbian equivalent of running from the dos command prompt.
Aside from enabling the essential automation of unit and regression tests, a key advantage of a text shell test harness is that the emulator will boot in a few seconds rather than the excruciating minutes required for the full S60 environment. In the text shell, the edit->build->run cycle frequency is vastly improved when compared with running a full UI app.
For the emulator, Symbian has a fairly convoluted way of supporting this use case and I always forget what the correct options are. So I’ve documented them here for Symbian 9.x.