Engineering, not computation?

I heard Noah Cowan of JHU give a great talk today. He talked about having an engineer's perspective, a systems perspective, applied to scientific questions in biology. There is so much to be learned about the neural control of animal behavior, and he and colleagues are figuring out how animals close the sensorimotor feedback loop. It turns out, for example, both theoretically and experimentally that cockroaches can't be using simple proportial control when they are running at 1.5m/sec along a wall, but a PD model does in fact predict pretty well the roach motion. Or there are these weakly electric knifefish that really like hiding inside tubes. If you move the tube around, it will look like the fish is attached to it with a spring as it follows along. And it turns out that a harmonic oscillator (spring-mass) mechanics model in fact correctly predicts the behavior at various frequencies of moving the tube around, whereas a kinematic model does not.

As I payed close attention to the controller-plant-feedback diagrams, the second-order differential equations and the low-pass, high-pass and band-pass filter discussions, I noticed that all of these useful tools have nothing to do with computation or a computational worldview. The engineer has a formidable toolbox for use in the science of neural control; the progress that can be made is remarkable. But what can a computer scientist bring to the table? What models, what theoretical tools?

It's pretty obvious to me that computation won't be helpful in figuring out the science of animal motion, in all its graceful and fast glory. So what kinds of biology questions might we address armed with our understanding of data structures, algorithms and complexity? Ideally, questions beyond proving this or that purportedly intelligent activity is NP-hard? My hunch (and I'm betting my research on it) is that our computational tools will be best employed in asking and answering questions at a level above that of the neural control of one organism. Instead, we can study the interactions, communications, and group-level behaviors of many organisms.

Bayesian models of human cognition notwithstanding.

A simple and bad algorithm for teaching

This term I'm teaching an undergraduate course in Artificial Intelligence (AI). I got the job just as the semester started, and so I didn't get a chance to develop my own approach to the teaching of this very splendid and worthwhile subject. Of course, as a mixed blessing, there came the inevitable recourse to Russell & Norvig, who've shepherded thousands of similar courses over the last 10 years, and all over the place.

Book and lecture notes in hand, I've been so far following my first pass at a teaching algorithm:

1. Read the chapter. Make sure you understand it.
2. Prepare lecture slides.
3. Do a couple of exercises. Choose a couple for the next problem set.
4. Go over the slides a couple of times, mumbling things you want to say that are not explicitly written on the slide.
5. Enter classroom; deliver lecture; forget to use all your little "pedagogical devices"; watch students yawn...
6. Goto 1

This is as boring for the poor souls in my class as it is unsatisfying for me. I've "only" lost 4 students so far (out of a high point of 19), mostly due to a harsh problem set early on. But I need to come up with a better algorithm.

At least I have a nice subroutine in the "deliver lecture" department. At the beginning of each class, I call on random students to tell me, in their own words, about the concepts we discussed last time. In the spirit of modularity and reuse, I took this feature from a library of little gems by a senior faculty in my department. Thank you, senior faculty!

On the complexity of stuff

Last post got me thinking, which in my case means asking lots of questions and refusing to think through the answers, at least at first. Later, arguably, I will forget all about these very pressing questions and so will never find the answers until one day, I read something written about this elsewhere and bemoan the passing of time and my laziness.

But back to the pressing questions. One afternoon over tea with Dr. Peshkin, I heard him express an excellent question: what is the complexity of physical objects? In computational theory, there are complexity classes for problems. If an abstract machine (whose abilities can be approximated by a modern PC) can find the answer in a relatively short period of time, it belongs to one complexity class (called the 'polynomial-time' class or P) . If you need a machine that's capable of pursuing several solution lines at a time and non-deterministically switching between them, then it belongs to another, intuitively harder class of problems (called NP for 'nondeterministic polynomial time'). There's more classes, but the point is: you can tell if a problem fits into one of them. This is a useful thing for writing programs: you don't want to tell your computer to do something that's provably going to take from now until the end of time.

So is there a similar classification for objects? Objects are kind of like problems if you try to make them with your new personal fabber (PF). You need to tell the fabber how to make them, of course. And thus I think we can define useful complexity classes for objects in terms of the fabber that can make them and the instructions that it would require.

But what's the complexity of a fabber? Why, it's the class of objects it can make! :-) There's got to be a better way of course, but maybe we can establish equivalence classes, like in computability theory. Push-down automata can solve context-free grammars. A 2D laser printer can build planar objects. OK, this is a really uninformative example, but I have to think more to come up with useful classes in the complexity of stuff.

For now, let's all agree that stuff is pretty complex.

On the computability of universal rapid-prototyping

The new issue of Seed magazine (No. 25) has an article on machines that can make a copy of themselves. Well, actually, they can only make all the parts (other than batteries) that are needed to make a copy of themselves. That's not half-bad either. A machine that's cheap (and for which the materials are cheap!) and that can make all the parts for a copy of itself -- that's a big step towards universal availability of rapid-prototyping. And that may very well lead to something like personal factories, by analogy with personal computers and a similarly revolutionary idea.

By the way, in addition to RepRap mentioned in Seed, Technocrati and tens of other online sources (presumably because the project is affiliated with Google?), Fab@Home and its inventor Evan Malone (then at Cornell) have been pursuing universal rapid-prototyping at least since 2006.

The very idea raises questions about the interplay of the computational and the physical. If you can readily manufacture articulated, controllable things in your home, how do you then make them do useful things? As of now, fabbers (for that is what we shall call these nifty machines) don't make computer chips or electronics as part of the process. But people are working on it, and it doesn't defy the imagination to consider building (programmable?) circuits directly into the fabricated parts. Ah. So many things to ask from a computational perspective. Here's one: what is the computational class of circuits built by a fabber? Meaning: what class of problems can these circuits compute? What about any physically realizable fabber? There's a research project in there, yours for free.

More on all that later.

Bayesian faith

I have often maintained that people who refuse to believe the mountains of accumulated scientific knowledge in domains where they have counter-scientific but unyielding faith aren't necessarily behaving irrationally. At the risk of being quoted out of context as supporting religious dogma over science (I don't, never have - if you quote this post, please quote its entirety), let me show you what I mean by that.

One of the intellectually rich contributions of computational thinking is the notion of Bayesian belief -- the idea that a rational agent must update its beliefs about possible events in the world based on some prior information and the evidence it sees. Sounds pretty straightforward, doesn't it? Well, maybe it doesn't until things are defined more rigorously. 'Belief' that X in this case is a probability the rational agent maintains in its mind that X is true. Classic example: do I believe I should take an umbrella with me today, as I go out to work (where else!?)? Well, that depends on what I a priori believe about the weather today (the forecast was for 40% chance of rain - maybe I shouldn't) and on what I see when I look out the window (evidence: menacing clouds ride low, gusts of wind seem to indicate a thunderstorm is on the way - oh-oh, maybe I should).

How exactly does one arrive at that decision, at that degree of belief? The beautiful thing is: there's a theorem about that. The best anyone can do was written down by a British Presbyterian minister by the name of Thomas Bayes in the 18th century. Bayes' theorem says that the likelihood of something is equal to its prior probability times the evidence, normalized. The trick is: if you a priori believe something to be 100% true (or false), then no amount of evidence to the contrary will sway you. To see that for yourself, check out the awesome intuitive introduction to Bayesian reasoning by Eliezer Yudkowsky (or the intuitive and short version by Kalid at BetterExplained), then try updating a prior probability of 1 in any of the examples.

It turns out that there is much evidence that our brain operates in a fashion consistent with Bayesian updating, on many levels from immediate visual perception (I can see the letters I'm typing but the higher-level prior context provided by my brain will prevent me from spotting some typos), to common-sense decision-making like in the umbrella example. The scientific method too can be described in Bayesian terms, as we inspect new evidence and deduce how much it discriminates between conflicting theories, and how much information is contained in it.

So, if Bayesian-like processes in our brains are responsible for rationality, and if you have 100% faith in something, then mathematically, no evidence will be of consequence. You will still believe your pet theory with 100% probability. Maybe that's how unquestioned beliefs operate: they aren't necessarily functionally unquestioned (the brain machinery is constantly at work) but the resulting belief is predictably stable.

But where could those crazily strong prior beliefs come from? That's a very important question, but one for another post.

Randy Pausch 1960-2008

RIP Randy Pausch, CS professor at CMU who achieved his childhood dreams and delivered a poignant "Last Lecture" when he was diagnosed with terminal cancer.

His main legacy is Alice, a free software tool that pretends to teach kids how to tell stories in 3D graphics, but really teaches them serious programming. Programming, in the words of Don Slater from the Alice promotional video, is telling the machine in front of you how to do what you need it to do. But instead of focusing on the minutia of a programming language syntax, it gives students the ability to easily create and animate 3D virtual inhabited worlds. The characters are objects with members and methods, and the environment supports variables, loops, conditionals, recursion, -- most things necessary for a thorough introduction to programming, which can be done entirely through a drag-and-drop interface where no mistakes can be made.

The trick is that the students' attention gets engaged from day one with a storytelling/world-building experience and without the frustration of compiler errors and segmentation faults. The Alice team cite statistics for at-risk students getting better grades and a lower drop-out rate in computer science. "At-risk" of course means students who don't fit the traditional CS mold, precisely the students CS departments would like to recruit and keep in the name of diversity, creativity, and a richer talent pool.

Basically, Alice is like an all-virtual Lego MindStorms on crack. For some reason, I think this sort of inappropriate language for an obit (which this isn't) would be appreciated by the late Prof. Pausch. Alice takes to university level what the Lego programming interface gave to younger kids: the same wonderment at just having created something with your own drag-and-dropping hands, at at watching it do its stuff. This is how many an engineer gets her calling.

Randy Pausch and the Alice team say: look, kiddo, you can take these abstract things and stack them any which way, and depending on how you do it, your machine will make you a world full of action and character, joy and meaning. This is so close to magic. And by the way, you have now learned Java. I wish I was learning to program all over again.

The Boston Phoenix weighs in on the eternal question

Will robots take over the world?
There's endless speculation, and I promise to post some links and actual commentary shortly, but meanwhile, I'm a little late in on this: http://thephoenix.com//Boston/Life/61912-Rage-against-the-machines/ (published May 28, 2008), where I sound like a total ass.