Wednesday, October 24, 2012

"Calculation and Tabulation in the Nineteenth Century: Airy versus Babbage"

Doron Swade's 2003 PhD thesis entitled "Calculation and Tabulation in the Nineteenth Century: Airy versus Babbage" is available for download.

It covers the interaction between Charles Babbage and George Airy and shines light on a relationship that has previously been reduced to caricatures of the two men.


Tuesday, October 16, 2012

A downloadable nanosecond

I came across a wonderful video of Grace Hopper (if you don't know who she is go read that Wikipedia article first and the come back here) explaining what a nanosecond is using a visual aid. The aid is a length of wire equal to the distance light travels in one nanosecond. That's 299.8mm (or as she puts it 11.8").


That's a handy length because it fits neatly on A4 and US Letter paper. So, here are downloadable nanoseconds that can be used to make the same point as Hopper. I've prepared both A4 and US Letter versions as PDFs.

Seeing the distance light travels in a nanosecond is interesting because it becomes clear that at the very high frequencies that computers operate at the speed of light and length of cabling become significant. This propagation delay is something that designers of very high speed circuits have to take into account. For example, a machine working 1 GHz has a clock that's ticking once every nanosecond.

Here are the two versions.


Friday, October 05, 2012

Plan 28 now accepting donations

Plan 28's donation system is now online through JustGiving. Donations can be made in British Pounds, US Dollars, Euros and a number of other currencies. As a UK charity Plan 28 is eligible for GiftAid; tax payers in the UK can help the charity by signing the GiftAid form when they make a donation.

As Plan 28 is a very long project it is particularly helpful when we receive regular donations. The donation system is able to set up monthly donations for people who want to contribute a little each month over the long term.

Plan 28 can accept donations on the web or via mobile phone. For example, to donate £10 by phone text BABB37 £10 to 70070.

Thursday, October 04, 2012

Web-scale Arduino

There are a number of projects that allow one to control an Arduino using node.js.  For example, there's Noduino and Johnny-Five. To my mind these things are an abomination(*) because they are teaching people to use Arduino at the wrong level of abstraction. If you are going to learn Arduino, learn some C.

One can always argue that they get more people using Arduino, but all these people would be better off learning some C for the joy of Arduino is not (to my mind) controlling it using a massive desktop or laptop machine. The joy of Arduino is small, embedded projects that do stuff. Such as Simonoids:
And if they learn some C they'll get more out of Arduino because they'll be able to do things that the node.js layers don't allow: cool stuff. And once they've learnt some C and need to control the Arduino from the host they'll be able to do even more cool stuff. If you are going to learn Arduino, learn some C.

To get an idea of what's problematic about 'web-scale Arduino' take a look at the canonical Hello, World! of Arduinoland: flashing the LED attached to pin 13.  Here's the code to do that in Noduino:

And here's the code to do that in C on the Arduino:
The first problem is that the Noduino code is nothing like the code on the Arduino. So, anyone learning to use Noduino is learning almost nothing about programming Arduino. The skill of using the duino library is not transferrable to writing code on the device itself. That's a problem because these node.js Arduino wrappers have limitations that can only be overcome by using C.

For example, LED.blink() takes care of all the flipping on and off of the LED and it performs the timing. And it's not just that it's doing the work, all the concepts in node.js (particularly of events) just don't exist on the Arduino. What you learn with Noduino is how to use Noduino; similarly for Johnny-Five.

(Aside: for a fun puzzle work out how to stop the LED from blinking in the node.js example.)

The other issue is that the really cool thing in node.js (the same code on the server and browser) just isn't true here. None of that JavaScript is running on the Arduino. You can't take your JavaScript and run it on the Arduino and so you can't, for example, take your LED-flashing Arduino, attach a battery to it and see it run.

Now, that might seem like a minor issue but doing things that are time sensitive (such as bit banging) means your code needs to be on the Arduino. Projects like the Cansole need to have very precise timing to generate the TV signal in software. That needs doing in C.
The way these systems work is by having a serial protocol defined between the Arduino and the host. Noduino uses duino and Johnny-Five uses Firmata. Projects that can live within the restrictions of those protocols will get along fine, but it means giving up access to the vast world of Arduino libraries.

(Aside: if you know C then you can use Firmata as a communication mechanism between your host program and Arduino and get the benefits of both worlds.)

As an example, if you wanted to connect a serial device (say a GPS) to some of the Arduino digital pins using SoftwareSerial you'd be in trouble. Or suppose you want to use TVout to generate a PAL or NTSC signal, you can't. If you know C you can hack that stuff into your project even if you use node.js to control the Arduino. C is the core language used by Arduino and it's worth learning.

Of course, having gone on about this there is a good reason to control an Arduino from a node.js program: if you are writing a web app that needs to control some external device then Arduino is a handy interface box.

And I'm not against doing that. In fact, the standard Arduino examples include many ways of combining a Processing program with an Arduino program. One example allows the user to move the mouse on their computer to control the brightness of an LED. All of these involve communicating using the serial connection (which is what Firmata and duino do under the hood) and require writing a simple Arduino program in C.  Another example uses the Arduino to read analog data and Processing to graph it.  In both case the programs used are small, simple and native and can take full advantage of the Arduino and the host.

In summary, I think you're missing a lot if you start with node.js as your way of learning Arduino. Flash an LED in C: it's easy.

(*) I am exaggerating for effect.

Tuesday, October 02, 2012

The Great Railway Caper: Big Data in 1955

The story of a Big Data problem in 1955 presented at StrataConf London 2012.


As soon as I have Tim Greening-Jackson's permission to share his research paper on "LEO 1 and the BR Job" I will update this blog post with information on how to get it.

PS Tim has kindly given permission to post his paper here.


Monday, October 01, 2012

Fact checking George Dyson (where he taps me on the shoulder)

It's no secret that I wasn't impressed by George Dyson's book "Turing's Cathedral" because it skewed history in a particular way a bit too much, and I felt that the title exploited the Turing anniversary. But I was struck by something he said in a StrataConf EU keynote.

He said that in 1953 there were only 53 kilobytes of random-access memory in computers in use and showed a picture of a February 1953 report entitled "A Survey of Automatic Digital Computers" published by the US Office of Naval Research. I thought that sounded odd, so I tracked down a copy of the report.


In fact, he makes the same claim in the book, but I'd overlooked it:


So, I started going through the report looking at machines that were operational in March 1953 according to the report. Just concentrating on binary machines I quickly found that random-access memory was well past 53KB.  By the time you reach E (the machines are in alphabetical order) there were 85,856 bytes of memory (in the ACE Pilot, APE(R)C, AVIDAC, BARK, EBIAC, CADAC, CSIRO Mark 1, EDSAC 1,  EDVAC, ELECOM 100 and ERA 1101).

So, then I wondered if, given that Dyson is oddly obsessed with the Williams Tube memory storage (making it the basis of his really odd "Turing Machines are one-dimensional, von Neumann machines two dimensional metaphor) if he was only counting machines that used fast electrostatic memory (he does, after all, say 'high-speed' in the book).

The machines that were operational in March 1953 with that type of memory are (according to the report): AVIDAC (5,120 bytes), ILLIAC (5,120 bytes), IAS Machine (5,120 bytes), Manchester Machine (645 bytes), MANIAC (5,120 bytes), ORDVAC (5,120 bytes), SEAC (2,816 bytes), SWAC (1,152 bytes), UTEC (768 bytes), Whirlwind (4,096 bytes).  That's a total of 35,077 bytes.

Reading the report it's clear that there was more than 53KB of memory in March 1953 and that it was spread across a variety of different memory types (magnetic drums, acoustic/mercury delay lines and electrostatic techniques).

It's a nice soundbite that in "1953 there were 53KB of memory", but like everything else in Dyson's book it's important to read it in the light of his fundamental idea that von Neumann's IAS machine is the Ur Machine.

PS After my talk at StrataConf I attended the FOO Party where all the speakers and others get together at the end of the conference. While chatting with someone, I felt a tap on my shoulder and turned round to hear "I really enjoyed your talk today. Marvellous to hear about LEO". The finger belonged to George Dyson.

So, of course, I had to own my opinions and ask him straight to his face about things I've written. I still don't understand his explanation of the one dimensional/two dimensional thing, but he convinced me that he's right about the 53KB in '53 thing. Apparently, there are two other important machines not mentioned in the US Navy report: one at IBM and another at RAND. He was just counting high-speed electrostatic memory as I'd guessed. And given that he spent 6 years researching the book he's probably got that part right!