David's Blague

Up to this point, all the code presented here is running in sequence. This is not, however, by design, so much it is by accident. Theoretically, every cell of a cellular automaton has access to its own tiny little computer (e.g. XOR gate), and it's own tiny little memory (e.g. 2 bits). And when we do that, we can start running them in parallel.

A somewhat more realistic approximation of this theoretical model would be to run enough cells on any given processor to fill up its memory, and to have it communicate without any friction with the adjacent processors.

There is no reason that a few of these babies couldn't run a cellular automaton with a trillion or so cells.

The hardware limitation to what we can effectively learn is rapidly dwindling. The only limitation to how well a curve can be fit is how well the underlying slice correlates to the curve. This is a matter of achieving sufficient parallelism, tweaking our models, and brute-forcing our way through enough cell-space to figure out what classes of data are good fits:

• A game of Rock-Paper-Scissors?
• A really, really random screensaver?
• A Random Walk?
• An encrypted file?
• A compressed data stream?

One of the beauties of this field is that it's not really theoretical- at least not in the sense that math or physics is theoretical. Well, at least theoretical physics. It's practical: either our models will match experimental data, or they won't.

There are open questions worth additional scrutiny.

Should we model using infinite, or finite grids?

What is the optimal structure of grids for various problem sets?

The only way we can find answers to these questions is to dive in and start hacking. If you're interested, email me.

I've now started the questions- if any of you here know the answers, feel free to pop me an email. Otherwise, I've hopefully stimulated a few questions.

Labels: cellular automata, deusexautomatis, etech