Last week I created a variety of rule sets for the game of life. I began this weeks work with the aim to combine several rule sets into one program. I began by attempting to create my own rule set from scratch. I was getting a better handle on how the code worked and was having more success with controlling the programs outcome. This was due in large part to the use of the 'print' statement. The rules are dictated by a series of if statements: if there are 3 neighbors than die etc. I put a print statement in each if statement and had it spit out a number (the first rule spit out one the second spit out two etc.). By doing this I was able to see which rules where firing and how often. In the process I found some interesting results.
Traditionally, Cellular Automata programs work by looking at each pixel individually every frame and comparing them with the surrounding pixels. I was working with a canvas size of 400 by 400 pixels and the program was set to run at 8 frames a second. That's 1,280,000 calculations per second. This is nearing the limit of Processing's power. When trying to understand code I like to use print statements to get a handle on what and when things are happening. With this program many calculations happen every frame Processing was not able to run with both the pixels being drawn and the print statements being displayed. I could do one or the other but not both. This made it very difficult to get a handle on what was happening. However the print results were interesting.
Click to view the printout as HTML. Your browser can zoom the text in and out. on mac: use "cmd & +/-" on pc "cntrl & +/-". Try it out.
Note: the white space is the number 1. At the zoom level the images was captured at the 1s don't show up.
This is the program used to make the printout.
These print outs are interesting to look at, but they also could act as blueprints for the game environment if it were to ever be developed further.
I made print outs of some of my other life programs to see the results. I continued tinkering with my code and gaining a better understanding of how the CAs worked. It became clear that I would need some kind of system to keep track of which rule set was
being applied. The different rule sets would also need to be
recognized by each other in order for the system to act as an
integrated ecosystem. There are many ways to do this, however because
of the sheer number of calculations being preformed each frame already
I needed a way that was fast. Integers are the fastest data type so I
decided to base the system around them. The way game of life program
that I am working with works, is by looking at each pixel and adding up
the value of it's neighbors. This total represents the number of
neighboring pixels that are turned on. If you have multiple rules
working together and iterating with one another this won't work because
the system will have no idea which rule is on. I developed a system
that would encapsulate all of the rules into one three digit integer.
The "blue" count would be held in the 'ones' place the "red" count
would be held in the 'tens' place and the green count would be held in
the 'hundreds' place. I than wrote a function that could parse the
three digit number and return which ever place was being checked. The
function follows:
int nb(int N, int num) {
for(int i =100; i >= 1; i=i/10) {
int x;
x = num/i;
num = num - i*x;
if(N==100) {
if( i == 100) { //green
return x;
}
}
if(N==10) {
if( i == 10) {//red
return x;
}
}
if(N==1) {
if( i == 1) { //blue
return x;
}
}
}
return 0;
}
The
function returns an integer. The first parameter is place that you
want returned ('1', '10', '100') and the second is the number of
neighboring pixels that are turned on (1-8 for blue, 10-80 for red,
100-800 for green). so num might be 232. That is 2 green 3 reds and
two blues. The function uses a for loop. Each loop variable x is set
to num and divided by i than it checks what value was entered and which
step the loop is on. If they match it spits out the number of
neighboring pixels of the specified rule set.
With this function I set out to combine the three rule sets starting with ones that I had conceived of in my note book.
visual sketches of rules:
I tried to implement these rules. The results were mixed, I was able
to get interesting results but as the program runs the output gets more
and more chaotic.

rule combination 1
I made several iterations of this rule set and had trouble gaining control. I than had the idea of applying my multiple rules method to some of the
life rule sets I had made previously and was successful. Below are the
results.
Ruleset 1
and
Ruleset 2
The result:
Combination of life 2 and life 3.
3 rule set combination
The atmosphere is the last component to add. Below is a composite of how the gas might look once it is added.
I found several cellular automata machines here is a good one if you want to experiment with them
http://www.fourmilab.ch/cellab/manual/chap5.html
Using techniques of mathematical logic, von Neumann was then able to deduce that such self-reproduction should in fact be possible. His proof hinged on the idea that an automaton could have a blueprint for building itself, and that in self reproduction, two steps would be necessary: 1) make an exact copy of the blueprint, and 2) use the blueprint as instructions for making a copy of the automaton. The role of the blueprint is entirely analogous to the way DNA is used in biological self-reproduction, for here the DNA is both copied and used as instructions for building new proteins.
The complexity of a reservoir full of floating machine parts hindered von Neumann from making his proof convincing. The next step came from Stanislaw Ulam, who was working with von Neumann at Los Alamos during those years. Ulam's suggestion was that instead of talking about machine parts in a reservoir, von Neumann should think in terms of an idealized space of cells that could hold finite state-numbers representing different sorts of parts.
Below are von Neumann's theories put into practice as software:
Wikipedia article here

Recent Comments