Authors: Rudy Rucker
Starting to write programs for the CAM-6 took a little bit of time because the language it uses is Forth. This is an offbeat computer language that uses reverse Polish notation. Once you get used to it, Forth is very clean and nice, but it makes you worry about things you shouldn’t really have to worry about. But, hey, if I needed to know Forth to see cellular automata, then by God I’d know Forth. I picked it up fast and spent the next four or five months hacking the CAM-6.
The big turning point came in October, when I was invited to Hackers 3.0, the 1987 edition of the great annual Hackers’ conference.
I got invited thanks to James Blinn, a graphics wizard who also happened to be a fan of my science fiction books. As a relative novice to computing, I felt a little diffident showing up at Hackers, but everyone there was really nice. I brought my computer along with the CAM-6 in it, and did demos all night long. People were blown away by the images, though not too many of them sounded like they were ready to (1) cough up $1500, (2) beg Systems Concepts for delivery, and (3) learn Forth in order to use a CAM-6 themselves. A bunch of the hackers made me take the board out of my computer and let them look at it. Not knowing too much about hardware, I’d imagined all along that the CAM-6 had some special processors on it. But the hackers informed me that all it really had was a few latches and a lot of fast RAM memory chips.
I met John Walker at Hackers 3.0. He told me a little about Autodesk and we talked in fairly general terms about my possibly doing some work with them. A month or two later, John showed up at my house with Eric Lyons, the head of the Autodesk Technology Division. They were toting a 386 and a five megabyte movie of Mandelbrot set zoom images that they’d made. I showed them all my new CA stuff, and they more or less offered me a full-time job. It was so sudden I wasn’t really ready to think about it.
Spring of 1988 I taught Assembly Language again, and this time just about all we did was write CA programs. The big revelation I had about getting the programs to run faster was to have no rigid preconceptions about what I wanted the program to do. Instead I began to listen to what the machine and the assembly language were telling me about what
they
wanted to do.
I found an inspiration for learning to listen to the machine in my favorite book, Thomas Pynchon’s
Gravity’s Rainbow.
In one scene some engineers are wondering whether to believe in their calculations or in the data that they are obtaining from tests on their prototype rocket engine. Enzian, an African wise man among the engineers says: “What are these data if not direct revelation? Where have they come from, if not from the Rocket which is to be? How do you presume to compare a number you have only derived on paper with a number that is the Rocket’s own?”
In my first spring at San Jose State, I was teaching a special course on Cellular Automata, and a custom chip designer called John Wharton had signed up for it. I’d met him at the Artificial Life Conference at Los Alamos in September, 1987, and he’d been at Hackers 3.0 as well. Wharton showed me how to use a stored lookup table for rapidly updating a one-dimensional cellular automaton four cells at a time.
Wharton and I talked a lot about how to make an inexpensive version of the CAM-6, whether by cloning the hardware or by reinventing the whole thing in software. I began trying to program something like this, and talked about the project with John Walker at Autodesk.
The semester ended, and the nice rental house my family and I had initially lucked into got sold out from under us for half a million dollars. Looking for a new place to house us on a professor’s salary, I realized that here in Silicon Valley I was really poor. I consoled myself by writing a lot more cellular automaton programs, a whole disk’s worth of them. I called the disk
Freestyle CA
, and sold about a hundred of them for $10 each via announcements in little magazines. (These programs still work on more modern machines, although now they run a little too fast. The
Freestyle CA
package as well as my later CA programs can be downloaded for free from my
site
.)
In June I heard that Eric Lyons was giving a talk on cellular automata at Autodesk. I went up, and after the talk I showed Eric my programs and asked if he and John had really meant it about offering me a job.
In July, John Walker mailed me a copy of his first version of what would eventually become the Autodesk software package called
CA Lab: Rudy Rucker’s Cellular Automaton Laboratory
. Walker’s program was such a superb hack that it could run CA rules nearly as fast at the CAM-6 board, but without any special purpose hardware. Not only did Walker’s program run my then-favorite CA rule called Brain maybe 30% faster than my best hack at the same thing, but his software was designed in such a way that it was quite easy for users to add new rules.
I began pushing really hard for the job. We went back and forth for a few weeks, and August 15 I started a three-month contract as a consultant at Autodesk. The main thing I did was to test out Stephen Wolfram’s new mathematics program
Mathematica
on a Mac II that Autodesk lent me. The idea was to use
Mathematica
to find some interesting new graphics algorithms. I found all kinds of things, but that’s a story for a different essay.
When my consulting contract ran out in November 1988, Autodesk still wasn’t quite sure about whether to really hire me full-time. That’s when I firmed up the idea that John Walker and I should pool all our CA knowledge and create the unified
CA Lab
product. I had a lot of ideas for new CA rules to feed to Walker’s simulator, and I could write the manual. Putting together
CA Lab
would be a specific thing I could do during my first year at Autodesk. The deal was okayed, and to make my joy complete, John magnanimously agreed to put my name on the package cover.
As I write this, it’s April 10, 1989, and we’re planning to ship the product next month. The code seems to be all done, and when I finish this section the manual will be done too, given one more frantic round of corrections.
So, okay, Rudy, finish it.
When I look at how completely cellular automata have transformed my life in the last four years I can hardly believe it. The most exciting thing for me to think about is how
CA Lab
going to transform the lives of some of you who use it; and how you in turn will change the lives of others around you.
A revolutionary new idea is like an infection that’s actually good for the people who get it. I caught cellular automata in 1985, and I’ve put them on
CA Lab
so you can catch them too.
What happens next? It’s up to you.
Note on “Cellular Automata”
Written 1989.
Appeared in the
CA Lab
manual, Autodesk, 1989.
After my initial interest in cellular automata, the magazine
Science 85
had hired me to do a number of articles for them in the past, so I convinced them to send me to Princeton and Cambridge to interview the new cellular automatists. The “Modern Cellular Automata” section of this essay was adapted from the article I wrote. As it turned out, an editor at
Science 85
found cellular automata too esoteric, so in the end the article actually appeared in
Isaac Asimov’s Science Fiction Magazine
, April, 1987.
CA Lab was an educational DOS software package for investigating cellular automata. I have to admit that my tone goes a little over the top about the virtues of cellular automata and Artificial Life. Certainly this was one of the least bland computer manuals ever written. The first edition of the manual even included the “brain-eating” scene from my novel
Software
as a footnote, though the vice-president of Marketing had this removed from subsequent printings.
John Walker, one of the founders of Autodesk, wrote most of the code for
CA Lab.
Although
CA Lab
is out of print, John Walker has created an improved freeware version of the program for Windows called
Cellab
.
Cellab
is available for download from my Web
site
or from Walker’s Web
site
. Walker’s site has many other goodies, such as the complete U. S. tax code. I think he gets something like a hundred thousand visits a day.
It’s worth mentioning that Walker was an inspiration for the character Roger Coolidge in my transreal novel
The Hacker and the Ants.
As John wasn’t quite satisfied with my ending—in which Roger Coolidge dies—he wrote his own alternate ending—in which Roger Coolidge lives. John’s alternate ending to
The Hacker and the Ants
can still be found on site.
Life and Artificial Life
Artificial Life is the study of how to create man-made systems which behave as if they were alive.
It is important to study life because the most interesting things in the world are the things that are alive. Living things grow into beautiful shapes and develop graceful behavior. They eat, they mate, they compete, and over the generations they evolve.
In the planetary sense, societies and entire ecologies can be thought of as living organisms. In an even more abstract sense, our thoughts themselves can be regarded as benignly parasitic information viruses that hop from mind to mind. Life is all around us, and it would be valuable to have a better understanding of how it works.
Investigators of the brand new field of Artificial Life, or
A-Life
, are beginning to tinker with home-brewed simulations of life. A-life can be studied for its scientific aspects, for its aesthetic pleasures, or as a source of insight into real living systems.
In the practical realm, Artificial Life provides new methods of chemical synthesis, self-improving techniques for controlling complex systems, and ways to automatically generate optimally tweaked computer programs. In the future, Artificial Life will play a key role in robotics, in Virtual Reality, and in the retrieval of information from unmanageably huge data bases.
One can go about creating A-Life by building robots or by tailoring biochemical reactions—and we’ll talk about these options later in this essay. But the most inexpensive way to go about experimenting with A-Life is to use computer programs.
What are some of the essential characteristics of life that we want our A-Life programs to have? We want programs that are visually attractive, that move about, that interact with their environment, that breed, and that evolve.
Three characteristics of living systems will guide our quest:
Gnarl
Sex
Death.
This essay includes sections on Gnarl, Sex, and Death, followed by three sections on
non-computer
A-Life.
Gnarl
The original meaning of “gnarl” was simply “a knot in the wood of a tree.” In California surfer slang, “gnarly” came to be used to describe complicated, rapidly changing surf conditions. And then, by extension, “gnarly” came to mean anything that included a lot of surprisingly intricate detail.
Living things are gnarly in that they inevitably do things that are much more complex than one might have expected. The grain of an oak burl is of course gnarly in the traditional sense of the word, but the life cycle of a jellyfish, say, is gnarly in the modern sense. The wild three-dimensional paths that a hummingbird sweeps out are kind of gnarly, and, if the truth be told, your ears are gnarly as well.
A simple rule of thumb for creating Artificial Life on the computer is that the program should produce output which looks gnarly.
“Gnarly” is, of course, not the word which most research scientists use. Instead, they speak of life as being
chaotic
or
complex
.
Chaos as a scientific concept became popular in the 1980s. Chaos can be defined to mean
complicated but not arbitrary
.
The surf at the shore of an ocean beach is chaotic. The patterns of the water are clearly very complicated. But, and this is the key point, they are
not arbitrary
.
For one thing, the patterns that the waves move in are, from moment to moment, predictable by the laws of fluid motion. Waves don’t just pop in and out of existence. Water moves according to well understood physical laws. Even if the waves are in some sense random, their motions are still not arbitrary. The patterns you see are drawn from a relatively small range of options. Everything you see looks like water in motion; the water never starts looking like, say, cactuses or piles of cubes. The kinds of things that waves “like to do” are what chaoticians call “attractors” in the space of possible wave behaviors.
Note that the quantum uncertainties of atomic motions do in fact make the waves random at some level. As Martin Gardner once said to me, “Quantum mechanics ruins everything.” But quantum mechanics is something of a red herring here. The waves would look much the same even if physics were fully deterministic right down to the lowest levels.
As it turns out, you don’t need a system as complicated as the ocean to generate unpredictable chaos. Over the last couple of decades, scientists have discovered that sometimes a very simple rule can produce output which looks, at least superficially, as complicated as physical chaos. Computer simulations of chaos can be obtained either by running one algorithm many times (as in a simulation of planetary motion), or by setting up an arena in which multiple instances of a single algorithm can interact (as with a cellular automaton). A sufficiently complex chaotic system can appear fully unpredictable.
Some chaotic systems explode into a full-blown random-looking grunge, while others settle into the gnarly, warped patterns that are known as strange attractors. A computer screen filled with what looks like a seething flea circus can be a chaotic system, but the fractal images that you see on T-shirts and calendars are pictures of chaos as well. Like all other kinds of systems, chaotic systems can range from having a lesser or a greater amount of disorder. If a chaotic system isn’t too disorderly, it converges on certain standard kinds of behavior—these are its
attractors
. If the attractors are odd-looking or, in particular, of an endlessly detailed fractal nature, they are called
strange attractors
.