PROGRAMMING PARADIGMS

Finding the Key to the Mini-Bar

Michael Swaine

Okay, okay, okay. There will be no politics in this month's offering. I don't know what came over me recently. I realize that this column is no place for bleeding-heart, pinko liberal ravings. That's what "Swaine's Flames" is for. Here's what is on this month's paradigmatic menu:

Quest for Chaos

I've written here before about Interactive Physics, an impressive product from KnowledgeGarden that simulates enough of the laws of classical physics to let you do virtual experiments. KnowledgeGarden's Dave Bazouki has come up with a variation on this theme in the form of a tool for the working engineer called "Working Model."

Looking for a simple physical system to construct in order to get a feel for the capabilities of Working Model, I turned to Scientific American, not the most logical place to look, I suppose. The physics in Scientific American is rarely classical; but a simple, classical-looking diagram immediately caught my eye. What it was demonstrating was not a simple concept, though; it was an illustration in an article about chaos theory.

The article, in the August 1993 issue, was called "Mastering Chaos" and was by William L. Ditto and Louis M. Pecora. It described how chaotic systems can be nudged into orderly behavior. Chaotic systems are nonlinear and highly sensitive to initial conditions; they usually appear random. They aren't random, though. The behavior in a chaotic system is a collection of many orderly behaviors, and the authors describe ways to disturb a chaotic system to make it follow one of its regular behaviors.

There are some interesting ideas in the article, but I halted when I saw the figure on page 80. The figure shows a simple mechanical apparatus consisting of a ball attached to a spring which is in turn attached to a board. The board is moved back and forth parallel to the length of the spring, and the ball bobbles back and forth with it.

Or sort of with it. At low speeds, the ball follows the motion of the board pretty closely. But as you start jerking the board back and forth more rapidly, the motion of the ball gets more erratic, and at a certain point it becomes chaotic.

The figure shows the movement of the ball in two series of graphs. The first plots position against time, and shows the motion starting out periodic, getting more messy, and finally going chaotic and looking random. The second plots velocity against position; it's a state-space map. It gives a different look at the same positions and movements of the ball, but in this state-space view, the motion of the ball never looks random. The chaotic stage looks like the path of a satellite around a double star, never retracing itself, but occupying only certain regions of (state) space.

So I implemented this simple system of block and spring and ball using Working Model. My goal was to duplicate, as closely as possible, the diagram in the magazine. For the diagram's series of graphs, my working model would have two live graphs, each tied to the appropriate parameters of the model. When I set the model running, the graphs would start drawing.

As it goes with these things, I spent too much time getting the objects the right sizes and shapes and colors. This was not much different from using a drawing program, and didn't teach me anything except that part of using Working Model is like using a drawing program. Associating properties with these objects and creating the necessary forces and setting up the graphs went faster, and was more interesting.

Then I gave the block a nudge to get it moving, and it was all parameter tweaking from then on. A lot of parameter tweaking. The motion really wanted to fall into stable cycles, but eventually I got curves that looked like the pictures in the magazine, demonstrating a chaotic attractor. I had achieved chaos.

So what was the point? Just to check out the program, I suppose. I admit that Interactive Physics and Working Model are only peripherally related to programming, but I can't believe that these products aren't interesting to anyone with an analytical mind. The idea of doing virtual physics experiments, checking the diagrams in Scientific American, fascinates me at least. And more and more, virtual experiments are becoming a part of what real scientists do.

Itty-Bitty Machines

What K. Eric Drexler does is something else, something he calls "theoretical applied science"--research that attempts to describe technological possibilities, with "possible" defined by a current understanding of physical law, not by the limitations of present-day techniques. In some cases, it wouldn't seem to require much research to show that a proposed device is counter to known laws of physics (perpetual-motion machines); in other cases, it might be more problematic (Star Wars). Drexler is interested in a case where determining whether an ambitious technological program is consistent with the known laws of physics is not just a tricky question, but a rich domain of research in several disciplines. Drexler wants to build molecule-scale machines and computers by moving molecules around. He calls it "nanotechnology."

What people call Drexler is "Mister Nanotechnology." He has written extensively on the field and is the president of Foresight Institute and Research Fellow at the Institute for Molecular Manufacturing, both organizations focusing on nanotechnology, both based in Palo Alto, California. His book Nanosystems: Molecular Machinery, Manufacturing, and Computation (Wiley Interscience, 1992) is the one to get if you're serious about this stuff: a broad and deep technical exposition of a nascent technology that sounds like sheer science fiction.

Specifically, what Drexler is talking about is "the construction of objects to complex, atomic specifications using sequences of chemical reactions directed by nonbiological molecular machinery."

On the face of it, it's hard to take seriously the idea of molecule-sized machines moving molecules around and manufacturing tiny products from them. The force that holds atoms together in molecules isn't like mortar; it's selective in what it bonds to what, it's subject to being pulled apart under quite natural circumstances, and a single bond doesn't provide any rigidity, since the atoms can rotate around the bond.

But the domain of possible molecular structures is so rich that Drexler not only can envision molecular machines, he has a choice of approaches to building them. He leans toward keeping things simple by using diamond-like substances in which you can, to some extent, keep track of where the atoms are. It turns out that there are an enormous number of these diamond-like substances.

There are also an enormous number of questions that have to be answered preparatory to building nanosystems. And by no means the least of these is where to start: Nanothinking is complicated by the fact that it will take nanotechnology to build the tools that nanotechnology will employ. Do you build the chicken first, or the egg?

Drexler has some at least tentative answers to these questions, but doesn't close off too many lines of inquiry. In fact, the book looks like what you'd have to read to begin developing a syllabus for a doctoral program in molecular nanotechnology. (Drexler has a doctorate in molecular nanotechnology, but I gather that he sort of put it together himself.)

Where his book gets really interesting is where Drexler starts building things. He sets out to show, in principle, as a practical exercise in theoretical applied science, how one could construct familiar mechanical structures from assemblies of molecules. The familiar mechanical structures that he describes include bearings, nuts and screws, springs, gears, rollers, belts, cams, clutches, and ratchets.

He describes in convincing detail how these molecular devices could work. Basically, these mechanisms are moving parts with sliding or rolling interfaces. His design guidelines--because that's what they are--for these mechanisms are based on careful study of the potential energy of interaction between two mutually inert surfaces in contact.

And on the behavior and properties of such surfaces, Drexler has lost of data, much of it in the book.

Camshaft Computers

Satisfied that nanocams and nanorods are possible, Drexler extends this line of thinking to the construction of very small computers, and he extends it in a surprisingly direct way. His envisioned nanocomputers are mechanical devices, built from tiny sliding rods and cams and nanomotors. A bit is encoded by displacement of a rod that can occupy one of two positions.

The reason appears to be that it's easier to work out the math that way. The collections of molecules he's dealing with in his models will have electrical properties, and these can, in principle, be used to carry and store information; but so can sliding rods, and the tiny distances involved make mechanical movement at least fast enough to be worth considering, so let's use 'em. So what if we're limited to signal transmission at the speed of sound, if that means 1/2 ns to go 1 micron, and that's about the width of a CPU in this technology?

Drexler starts building his envisioned nanocomputer with interlocks. An interlock is an arrangement in which a rod's mobility is controlled by another rod's displacement because a protrusion (called a "knob") on the side of the first rod is blocked or not blocked by a similar knob on the side of the other rod. It is, in effect, a mechanical transistor. From interlocks, he can build logic rods (logic gates).

A logic rod might have all of the following components:

It's tempting to draw analogies to other systems. The housing that encloses the rod or interlock and constrains rod motion to one dimension is like the insulation on a wire, both structurally and functionally. Another intriguing analogy is with certain cell states in cellular automata, so-called sheath states that form barriers between domains of cells (see Artificial Life by Steven Levy, Random House, 1992, page 100). But it's more than tempting; in a field as slippery as nanotechnology, one needs to make some simplifying choices. Analogies with other fields provide a frame of reference in this complex and unfamiliar realm.

Interlocks have a lot of features that are desirable in a transistor-like device: They support fan-in and fan-out, switch rapidly, make reliable binary decisions, pack densely, work with interconnections at their own scale, and restore signals to a reference level at each step. Their main drawback is that they don't exist yet. Some of the elements of nanotechnology have been created, though, like molecular rods and (sort of) gears. And when you read Drexler's descriptions, with molecular diagrams, it's not so hard to believe that interlocks soon will exist, too.

But interlocks aren't enough. You can't build a computer using only logic. Some memory also comes in handy. But in principle, Drexler demonstrates, creating nanotechnological registers and RAM arrays is no harder than building nanotech logic.

Okay, now we've got, in principle anyway, logic and memory. How can one resist? Let's build a computer. Alas, the details are too extensive for this space; see Drexler's book for the plans.

Although he doesn't really "build" anything too ambitious: Using PLA structures of logic rods and rod-based registers, he demonstrates how to duplicate, pretty much device-for-device, a controller design described in Mead and Conway's classic book on VLSI. Extrapolating from that, a RISC computer based on this kind of design ought to be capable of >1000 MIPS, and a 106 transistor (really, interlock) CPU should be able to fit in a 400 nm cube and consume about 60 nW.

He also discusses tape storage, input, and output. For tape, he uses a polymer chain that has two distinct side groups, giving a binary choice with every other carbon atom, for a practical storage density of around 5 x 1021 bits/cm3. For input and output (that is, connections to macroscale components), he envisions using tunneling junctions and electrostatic actuators.

Now, seriously: Has anyone actually shown that any of this can actually be done? No, and in fact Drexler has only examined its physical possibility at one level of analysis: the level of a bounded continuum model. It would be more convincing to have a proof of possibility done at the level of atoms and bonds. Drexler calls this an "open and accessible" problem.

Drexler's Program

But there's a prior question: Even given that these sorts of devices are, in principle, possible, could we actually build them? Drexler's analyses of these devices show, at best, that if the atoms happened to fall together in the right order, they would behave in accordance with his models. But is it possible to get them in that order, to get from here to there? Can we do molecular manufacturing?

Believe it or not, Drexler even has some things to say about the costs of goods produced in the molecular factory of the future. He discusses many of the issues relevant to manufacturing goods, in fact.

But that's apparently more theoretical applied science. What one wonders going through this book is, how do we get from here to there? And eventually Drexler addresses that question, and, as he does with other questions, he provides a choice of answers. The bottom line, though, seems to be that the tools now exist to develop new tools that could be used to develop new tools that could...I'm getting lost. Four stages of tools to make tools is what Drexler envisions before we have the nanotechnological factories that he envisions.

And that's why he spends his time doing theoretical applied science: Because the path he draws is so arduous and long, you'd better be darned sure that where you're headed is at least theoretically possible before setting out.


Copyright © 1993, Dr. Dobb's Journal