Wednesday, March 25, 2015

Automation automation automation

Lately the word "automation" has been pounding in my head, left and right. It came first in an enlightening conversation about what makes an enthusiastic Computer Science major. One of the key tenets that many agreed on was "a general interest in automation", which was funny, because, before now, I'd never considered my interest to be about automation... Sure there's robots, and AI, and OOP concepts-- but I've never thought of it as automation, even in my theory course, where I can't say a sentence doesn't contain the word "automata" in some form or another (make a Regex statement for that, why don't you!).

The wound opened further when reading Turing's defense of the ACE project, when Womersley brought proposed the project. One of the questions regarding the project's difference from other machines of that time was "What if the machine was given a series thought to converge, but actually diverged?". Without going into too much detail, Turing replied that it was the controller's responsibility to create a protocol to follow if this were the case. He added, somewhat sarcastically, that he hoped that the operator would be familiar enough with series to understand that this may occur.

He went on to say that the big draw of this machine was its automation, in that the role of the "human" computer could finally be significantly reduced, if not removed altogether, as the machines at the time still required a significant amount of human interaction through testing, verification, the like. It was thought that ACE would require only a few of the higher scientific staff to handle it, and allow the National Physical Laboratory to do away with the rest of the lower "human" computer staff. That's right, the replacement of almost an entire department through the massive reduction of man-hours, all made possible with automation.

I faced a similar issue today. After a bit of a "false alarm" in terms of correct Enigma machine outputs, I went to begin adding manual ring settings, when I found that not all of my inputs were working (...wait for it). I was a bit devastated. After some mucking about, I picked up my pen, and resolved that I would write down what all of the intended outputs should be, and compare them to outputs as they changed. However, before I put the pen to paper, I realized there was a better way. I decided to make my own testing suite in prolog, building an "equals" predicate, and a predicate that evaluated the equality of each item in a list, outputting 1's if they were correct with the inputs, and 0's if they were not. I also displayed the initial alphabet, my enigma results, as well as the correct enigma results.

some boo-boos... but why?

This allowed to drastically reduce the amount of "eyeballing" needed to just stepping through the troubled letters to see exactly what was wrong... An ironic scenario, because, as it turns out, I had written down my B reflector incorrectly! What are the odds! I fixed it, and finally got back all ones. :)

Highlighted reflector plate, corrected outputs.

The experience allowed me to learn something very important about automation:
It comes down to the fact that, a little time spent in automation can save you days of man hours, whereas you are doomed to repeat long hours "eyeballing"-- time spent that can also be in error. Reduce the eyeballing to a minimum and let the machinery do the rest for you! If there's five minutes reviewing large data sets, that adds up to an hour after only twelve runs.

No comments:

Post a Comment