from the perspective of my research, the size of the parameter space is the `generality' spectrum from power-procedure to shading-procedure to shading-language: the procedure/interpreter axis. in cellular automata, say: life, sum-lut, lut, n-lut, and ga-ca.

life

Conway's original, one bit per cell. no parameters.

8sum-life

look-up-table (lut) indexed by sum of neighbors and center. conway's is [[000100000][001100000]] (see CAM p20). parameterized by 18 bits.

lut

lut indexed by neighbors. parameterized by bits.

n-lut

handles n-bit cells. parameterized by bits. practical only for small n.

ga-ca

handles n-bit cells (and more). parameterized by recursively defined programs.

the final system, ga-ca uses code sequences instead of luts to save memory, making practical experimentation with larger n (larger parameter spaces). Refer to language of this code as CANL.

most existing programmable CA systems allow the programmer to write the CA rule in a the high-level language CANL (forth is popular). the rule is then executed on all possible neighborhoods to build a lut. in language terms, the rule is compiled into an intermediate code (the lut). (hint: why not compile it to machine code?) (note: the CAM people use special-purpose hardware to implement the lut-interpreter).

why do they do this instead of just calling a CANL interpreter on each cell neighborhood? basically, because it's hard to write a fast data-parallel interpreter. see proposal/buffering for more. existing systems either:

• write rules in C and recompiling to try each variation (so the program as the `user' sees it is not parameterized)
• write rules in CANL and compile to luts, thus limited to low-bit cells

• write a high-performance CANL interpreter using batching (losing latency and some bandwidth)
• use RTCG to compile CANL programs to machine code

though i don't know of any good examples of either, [Apply] comes close to the latter. building the software tools to support such RTCG is the focus of my thesis research. see proposal/alternatives.mar

the succes of this `inversion' of lut to code depends on which CAs we are interested in (the object-space), and what language the code sequences are `written' in. this is essentially the hope/assumption of koza-style GP systems: in the coordinate-system of CA space supplied by expression trees, it's 1) easy to express object-space points, and 2) those points are dense enough in terms of the distance metric: the mutation operators.

to explore different languages---to try out new coordinate systems for genetic search---is the motivation for lightweight languages.

alife bomb

what does alife have to do with bomb? is bomb alive? bomb uses various combinations of images, cellular automata, IFS fractals, but so far no GA. it's parameterized by roughly a dozen integers and several tens of doubles, but it lacks a recursive parameter.

working on `bomb' has basically been a sequence of generalizations. i start with an existing effect, then make some constant into a variable, thus expanding the range of effects and increasing the parameter space. bomb.

once my thesis is far enough along i'll add some GA rules to bomb, bumping its `vitality' up a notch.