Just a quick update to let you all know that I'm still in the running for the coveted Retrochallenge prize, if I can actually pull my finger out and write some code (no sniggering wgoodf!) We arrived at the campsite yesterday (Friday - although setting the date on your watch to the day before which is what I did created all sorts of interesting conversations between myself and my wife!) and I've sussed that I can get wifi signal to my tent (what a luxury that is!) but at 25 euros for a week I'll wait a day so I can catch the inevitable scrabble to the end of the competition.
Satellite Navigation - don't you just love it? The inbuilt navigation in our car failed a good six months ago and knowing that it'll cost a small fortune to fix I borrowed a Garmin GPS unit. I downloaded the appropriate French maps and even found the street the campsite was on to the very number. Our six plus hour drive promising to be a predictable one. However, all this is moot if the thing then freezes every 20 minutes or so, with no real indication of the fact except that the countdown to the next junction doesn't - countdown that is. I leave an open question to our knowledgeable retrochallengers - who has ever owned a satnav system that didn't, at some point, jump from a longer predicted time to a shorter predicted time when you chose the route. Is it like a game of chess - are there too many permutations to your destination that there is no possibility of it predicting that there might be a shorter route? In the end our predicted journey time dropped by 30 minutes by steadfastly sticking to the route chosen by google maps. It seemed like the most obvious and direct route. I guess it's born of experience, but I would say we are a long way off the software in satnav systems being foolproof. Possibly, without resorting to genetic algorithms, or building in so much 'local' knowledge that eventually the kind of information that a local would know is part of the system, I don't think the map makers should be too worried. I welcome your thoughts to @urbancamo, which I will retweet to @retrochallenge. The promise of satellite navigation systems is an alluring one. On a holiday with lists of things to bring and tasks to do as long as your arm, not having to worry about where you're going is a weight off your mind. However, the reality is that you have to be in control. I liken it to a pilot programming the autopilot at the start of a flight with all the details then pressing the 'go' button when positioned at the end of the runway. This is mostly possible - the latest autopilot systems can be engaged just after takeoff and will bring the plane to a complete stop at the end of the destination runway, applying appropriate braking and keeping the plane on the centreline. That's not what happens though, is it? For good reason - the human provides experience and wisdom that has proven very difficult to program into a computer.
Apollo Guidance Computer
By the miracle of waffle my blog post is brought back on topic. The apollo guidance computer was programmed at MIT, and was the first contract to be awarded on the Apollo programme. The same computer ended up being installed in both the command module and the lunar module (with different parameters clearly). The memory was core memory, mostly read-only, that had to be painstaking constructed by threading wires though the tiny cores (ferrite rings) to encode the '1's and '0's making up the program. These were constructed by an army of (mostly) women, leading to the affectionate acronym of 'LOL memory' of 'Little Old Lady' memory. It took the best part of six months to hand-wire the entire program required - I can't imagine the pressure on the programmers knowing that any bugs introduced in the system were not repairable in a reasonable timescale.
The software was written using a priority scheduler that would choose tasks to complete based on their importance. This proved invaluable on the Apollo 11 mission when what at first appeared an oversight in the software which caused a number of errors to be presented to the lunar pilot (because the computer was overloaded and dumping lower priority jobs) turned out to be the software working correctly in prioritising the guidance tasks over other tasks (such as the assessment of whether the landing should be aborted). These other tasks were meant to be running into that phase of the flight, but this had been overlooked during testing. The flexibility in the software took this into account. Anyone who has programmed complex systems knows that to write code that works correctly even in unpredictable circumstances is a very difficult task. Maybe, therefore, I shouldn't be too hard critisizing satnav systems (and by inference the programmers who wrote the software) and should treat them more as a aid to navigation rather than a method of navigation.