<input id = "myInput"
         type = "text"
         data-constraints = '@NotEmpty @IsNumeric @Between(min=1, max=5)'>

That bit of code describes a text box which cannot be empty, and which expects a numeric value between 1 and 5. With this basic design in mind, I started working on my framework. It took me about a week of on-and-off work (maybe 3 days actual work) but I’ve come up with something that is, in my humble opinion, a flexible and easy to use framework. I plan to document the use of this library/framework more thoroughly, but this post should serve as a gentle introduction to the framework and its features.

In Regula (which, by the way, means “rule” in Latin) form elements (input elements or even the form elements) can have constraints attached to them in a similar fashion to the example I described earlier. There is a small difference, however:

<input id = "myInput"
         class = "regula-validation"
         type = "text"
         data-constraints = '@NotEmpty @IsNumeric @Between(min=1, max=5)'>

As you can see, I use a class name of regula-validation which tells the framework that this input element has constraints attached to it. The reason I did this was for efficiency reasons. It’s much more efficient to grab all elements that have a class name of regula-validation than walking the whole document tree to search for nodes that have a data-constraints attribute.

After you annotate the input elements with their constraints, you’re halfway there already! All you have to do after that is add a script tag for the framework:

  <script type = "text/javascript" src="regula.js"></script>

And then add the necessary Javascript to validate the form (example uses jQuery):

jQuery(document).ready(function() {
    // must call this first. The best place would be in an
    // onload handler. This function looks for elements with
    // a class name of "regula-validation" and binds the
    // appropriate constraints to the elements
    regula.bind(); 

    jQuery("#myForm").submit(function() {
        // this functions performs the actual validation
        var validationResults = regula.validate();

        for(var index in validationResults) {
             var validationResult = validationResults[index];
             alert(validationResult.message);
        }
    });
});

That’s pretty much all there is to it. More advanced uses of the framework don’t deviate that much from this pattern. Compared to other form-validation frameworks (that I’ve seen), validation will not stop on the first failing element. The validate function runs through every input element and validates it against the constraints bound to that element, and returns an array of “validation results”. Each “validation result” element in the array has the following properties:

• constraintName – the name of the failing constraint
• custom – a flag that says whether this is a custom constraint or not
• constraintParameters – An array of objects that represents the parameters passed to this constraint (defined in the HTML. For example @Max(max=5), where you have a parameter who’s name is max and who’s value is 5. There’s a little more to this, but like I said, this is supposed to be a gentle introduction )
• receivedParameters – A hash (organized such that the name of the parameter is the key, and the value is well, the value) of parameters that the validator function received (helpful when you have a custom validator).
• failingElements – An array containing references to the actual input element or elements (in the case of form-specific constraints) that failed the constraint.
• message – The error message.

An interesting thing I noticed was that I couldn’t perfectly emulate the input instruction. I’m feeding the brainfuck code to the interpreter from STDIN and so that might be the problem. I’ve noticed that brainfuck interpreters written in brainfuck have the same problem. You have to specify program input before hand. This is what I’ve decided to do. You write brainfuck code, and then mark the end of program code by an exclamation mark. After the exclamation mark, you provide any input, and then mark the end of input by another exclamation mark. Programs that do not have any input end with two exclamation marks. After I finished writing the interpreter, I commented it. While I was doing this, I noticed a lack of labels in bAdkOde. So, I decided to update the interpreter to include them. Speaking of which, I really ought to rewrite the interpreter sometime…

Anyway, here is the code to the interpreter. I’m providing a link to it, because the commented version is rather large. But here’s the expanded (without labels or macros), unformatted version:

>3a>1b{!b?b>b[a)b-91b{=b+1[b>1b}+91b-93b{=b-1[b>1b}+93b(b+1a-33b}>0[a+1a>2b>a[b>1b{!b?b>b[a+1a-33b}>1b>a[b>0a>[aa>ab{=a>1a>[ab>3a{![a)a>[aa-62a{=a+1b-30000b)a>ba{+b>1b>[bb)b>0b-1b>0a}{-a+30000b)b>0a}(b(a+62a}+62a-60a{=a-1b)a>1a>[aa-ab>ba{-b>1a>[aa+30000a>ab)b>0b>0a-1a}{+a>1a>[aa+ab)b>0a-1a}(b(a+60a}+60a-43a{=a+1[b+43a}+43a-45a{=a-1[b+45a}+45a-46a{=a"[b+46a}+46a-44a{=a)a>2a>[aa>[a[b>2a+1[a(a+44a}+44a-91a{=a(a)b)a>[bb{=b>0b>1[b{![b(a+1a)a>[aa)a-91a{=a+1[a>1a}+91a-93a{=a-1[a>1a}+93a(a}(a-1a)a>1b}(a(b)a+91a}+91a-93a{=a(a)b)a>[bb{!b>0b>0[b-1[b{![b(a-1a)a>[aa)a-91a{=a+1[a>1a}+91a-93a{=a-1[a>1a}+93a(a}>0b}(a(b)a+93a}+93a(a+1a}>1a>0b}{!b"85"110"109"97"116"99"104"101"100"32"98"114"97"99"107"101"116"115>0b}

Also, this is additional proof for Turing Completeness. Yes, I’m a nerd!

1. The a register is our memory pointer.
2. We initialize the a register to 0.

Proof

We translate Brainfuck to bAdkOde using the following mappings or rules:

1. > maps to +1a
2. < maps to -1a
3. + maps to +1[a
4. - maps to -1[a
5. . maps to "[a
6. , maps to ?[a
7. [ maps to {![a
8. ] maps to }

Conclusion

Since we can completely translate or map Brainfuck, an already Turing-Complete language into bAdkOde, we can say that bAdkOde is also Turing Complete.

Translated example

helloworld.bf:

+++ +++ +++ +
[
    > +++ +++ +
    > +++ +++ +++ +
    > +++
    > +
    <<< < -
]
>++ .
>+.
+++ +++ +.
.
+++ .
>++ .
<<+ +++ +++ +++ +++ ++.
>.
+++ .
--- --- .
--- --- --.
>+.

helloworld.bad

>0a+1[a+1[a+1[a +1[a+1[a+1[a +1[a+1[a+1[a +1[a
{![a
    +1a +1[a+1[a+1[a +1[a+1[a+1[a +1[a
    +1a +1[a+1[a+1[a +1[a+1[a+1[a +1[a+1[a+1[a +1[a
    +1a +1[a+1[a+1[a
    +1a +1[a
    -1a-1a-1a -1a -1[a
}
+1a+1[a+1[a "[a
+1a+1[a"[a
+1[a+1[a+1[a +1[a+1[a+1[a +1[a"[a
"[a
+1[a+1[a+1[a "[a
+1a+1[a+1[a "[a
-1a-1a+1[a +1[a+1[a+1[a +1[a+1[a+1[a +1[a+1[a+1[a +1[a+1[a+1[a +1[a+1[a"[a
+1a"[a
+1[a+1[a+1[a "[a
-1[a-1[a-1[a -1[a-1[a-1[a "[a
-1[a-1[a-1[a -1[a-1[a-1[a -1[a-1[a"[a
+1a+1[a"[a

Here's a quick perl script that I whipped up, to translate Brainfuck to bAdkOde:

#!/usr/bin/perl

 use strict;

 my $terminator = $/;
 undef $/;
 my $bf = <STDIN>;
 $bf =~ s/[^<>\[\]\.,\+\-\s\n]//g;
 $/ = $terminator;

 my $i = 0;

 print ">0a";

 while($i < length($bf)) {

    my $bf_instruction = substr($bf, $i, 1);

    if($bf_instruction eq '>') {
       print "+1a";
    }

    elsif($bf_instruction eq '<') {
       print "-1a";
    }

    elsif($bf_instruction eq '+') {
       print "+1[a";
    }

    elsif($bf_instruction eq '-') {
       print "-1[a";
    }

    elsif($bf_instruction eq '.') {
       print "\"[a";
    }

    elsif($bf_instruction eq ',') {
       print "?[a";
    }

    elsif($bf_instruction eq '[') {
       print "{![a";
    }

    elsif($bf_instruction eq ']') {
       print "}";
    }

    else {
       print $bf_instruction;
    }

    $i++;
 }

Additional proof

Since there exist self-interpreters for Brainfuck (i.e., Brainfuck interpreters written in Brainfuck), and since it has been shown that there exists a valid translation from Brainfuck to bAdkOde, it follows that it is possible to write a Brainfuck interpreter in bAdkOde. This provides additional proof for the Turing Completeness of bAdkOde.

 print " \@body = (\n";
 map { printf "0x%x, ", $_ } @body;
 print " );\n";
 map { printf "%c", $_ } @body;

Here, you can see that I’ve decided to use an array called @body to store the ASCII values (in hexadecimal). The first three lines print out the definition for the array that will hold the ASCII values. The last line reads the array, translates the code into actual characters, and prints them out. Now all we have to do is get the hexadecimal codes and create the array. To do that, we use a utility called xxd:

vivin@dauntless ~/Projects/code/perl/quine
$ xxd -i quinegen.pl >qhex.pl

The output is an array definition in C:

unsigned char quinegen_pl[] = {
  0x20, 0x70, 0x72, 0x69, 0x6e, 0x74, 0x20, 0x22, 0x20, 0x5c, 0x40, 0x62,
  0x6f, 0x64, 0x79, 0x20, 0x3d, 0x20, 0x28, 0x5c, 0x6e, 0x22, 0x3b, 0x0a,
  0x20, 0x6d, 0x61, 0x70, 0x20, 0x7b, 0x20, 0x70, 0x72, 0x69, 0x6e, 0x74,
  0x66, 0x20, 0x22, 0x30, 0x78, 0x25, 0x78, 0x2c, 0x20, 0x22, 0x2c, 0x20,
  0x24, 0x5f, 0x20, 0x7d, 0x20, 0x40, 0x62, 0x6f, 0x64, 0x79, 0x3b, 0x0a,
  0x20, 0x70, 0x72, 0x69, 0x6e, 0x74, 0x20, 0x22, 0x20, 0x29, 0x3b, 0x5c,
  0x6e, 0x22, 0x3b, 0x0a, 0x20, 0x6d, 0x61, 0x70, 0x20, 0x7b, 0x20, 0x70,
  0x72, 0x69, 0x6e, 0x74, 0x66, 0x20, 0x22, 0x25, 0x63, 0x22, 0x2c, 0x20,
  0x24, 0x5f, 0x20, 0x7d, 0x20, 0x40, 0x62, 0x6f, 0x64, 0x79, 0x3b, 0x0a
};
unsigned int quinegen_pl_len = 108;

We need to change this to valid Perl, and that’s quite simple:

 @body = (
   0x20, 0x70, 0x72, 0x69, 0x6e, 0x74, 0x20, 0x22, 0x20, 0x5c, 0x40, 0x62,
   0x6f, 0x64, 0x79, 0x20, 0x3d, 0x20, 0x28, 0x5c, 0x6e, 0x22, 0x3b, 0x0a,
   0x20, 0x6d, 0x61, 0x70, 0x20, 0x7b, 0x20, 0x70, 0x72, 0x69, 0x6e, 0x74,
   0x66, 0x20, 0x22, 0x30, 0x78, 0x25, 0x78, 0x2c, 0x20, 0x22, 0x2c, 0x20,
   0x24, 0x5f, 0x20, 0x7d, 0x20, 0x40, 0x62, 0x6f, 0x64, 0x79, 0x3b, 0x0a,
   0x20, 0x70, 0x72, 0x69, 0x6e, 0x74, 0x20, 0x22, 0x20, 0x29, 0x3b, 0x5c,
   0x6e, 0x22, 0x3b, 0x0a, 0x20, 0x6d, 0x61, 0x70, 0x20, 0x7b, 0x20, 0x70,
   0x72, 0x69, 0x6e, 0x74, 0x66, 0x20, 0x22, 0x25, 0x63, 0x22, 0x2c, 0x20,
   0x24, 0x5f, 0x20, 0x7d, 0x20, 0x40, 0x62, 0x6f, 0x64, 0x79, 0x3b, 0x0a
 );

We take this and paste it on top of our core:

 @body = (
   0x20, 0x70, 0x72, 0x69, 0x6e, 0x74, 0x20, 0x22, 0x20, 0x5c, 0x40, 0x62,
   0x6f, 0x64, 0x79, 0x20, 0x3d, 0x20, 0x28, 0x5c, 0x6e, 0x22, 0x3b, 0x0a,
   0x20, 0x6d, 0x61, 0x70, 0x20, 0x7b, 0x20, 0x70, 0x72, 0x69, 0x6e, 0x74,
   0x66, 0x20, 0x22, 0x30, 0x78, 0x25, 0x78, 0x2c, 0x20, 0x22, 0x2c, 0x20,
   0x24, 0x5f, 0x20, 0x7d, 0x20, 0x40, 0x62, 0x6f, 0x64, 0x79, 0x3b, 0x0a,
   0x20, 0x70, 0x72, 0x69, 0x6e, 0x74, 0x20, 0x22, 0x20, 0x29, 0x3b, 0x5c,
   0x6e, 0x22, 0x3b, 0x0a, 0x20, 0x6d, 0x61, 0x70, 0x20, 0x7b, 0x20, 0x70,
   0x72, 0x69, 0x6e, 0x74, 0x66, 0x20, 0x22, 0x25, 0x63, 0x22, 0x2c, 0x20,
   0x24, 0x5f, 0x20, 0x7d, 0x20, 0x40, 0x62, 0x6f, 0x64, 0x79, 0x3b, 0x0a
 );
 print " \@body = (\n";
 map { printf "0x%x, ", $_ } @body;
 print " );\n";
 map { printf "%c", $_ } @body;

Now the interesting thing here is that this piece of code is not the actual quine. Rather, it generates the quine. But the generated code isn’t that different from the generator:

 @body = (
0x20, 0x70, 0x72, 0x69, 0x6e, 0x74, 0x20, 0x22, 0x20, 0x5c, 0x40, 0x62, 0x6f, 0x64, 0x79, 0x20, 0x3d, 0x20, 0x28, 0x5c, 0x6e, 0x22, 0x3b, 0xa, 0x20, 0x6d, 0x61, 0x70, 0x20, 0x7b, 0x20, 0x70, 0x72, 0x69, 0x6e, 0x74, 0x66, 0x20, 0x22, 0x30, 0x78, 0x25, 0x78, 0x2c, 0x20, 0x22, 0x2c, 0x20, 0x24, 0x5f, 0x20, 0x7d, 0x20, 0x40, 0x62, 0x6f, 0x64, 0x79, 0x3b, 0xa, 0x20, 0x70, 0x72, 0x69, 0x6e, 0x74, 0x20, 0x22, 0x20, 0x29, 0x3b, 0x5c, 0x6e, 0x22, 0x3b, 0xa, 0x20, 0x6d, 0x61, 0x70, 0x20, 0x7b, 0x20, 0x70, 0x72, 0x69, 0x6e, 0x74, 0x66, 0x20, 0x22, 0x25, 0x63, 0x22, 0x2c, 0x20, 0x24, 0x5f, 0x20, 0x7d, 0x20, 0x40, 0x62, 0x6f, 0x64, 0x79, 0x3b, 0xa,  );
 print " \@body = (\n";
 map { printf "0x%x, ", $_ } @body;
 print " );\n";
 map { printf "%c", $_ } @body;

The only difference is the extra comma in the array definition, and the fact that all the ASCII codes are on one line. If you run this perl script, you will get an exact copy of its source code. Now how do we write a quine in bAdkOde? We use a similar approach. First we write the core:

>0a
"62"48"97"10
{![a
 "62'[a"91"97"43"49"97
 +1a
}
"10
>0a
{![a
 "[a
 +1a
}

To implement a quine in bAdkOde, I decided to store the representation of the core (in decimal ASCII values) in memory starting at location zero. The first line initializes the a register to zero. The second line prints out the string >0a with a newline. This line is analogous to the print " \@body = (\n"; line in the perl quine. Within our first loop, we're printing out the actual code that will store the representation of the core in memory. So the first line within the loop prints >ASCII[a+1a where ASCII is the ASCII value of a character from the core. The line is analogous to the printf "0x%x, ", $_ line in the perl quine. There is another print statement right outside the first loop, which simply prints a newline. This line is analogous to the print " );\n"; line in the perl quine. The second loop performs the actual translation of the ASCII code into the core. Now, just like the perl quine, we use xxd:

vivin@dauntless ~/Projects/code/perl/bAdkOde
$ xxd -i quine.bad >qhex.txt

After doing this, we get C code that looks like this:

unsigned char quine_bad[] = {
  0x3e, 0x30, 0x61, 0x0a, 0x22, 0x36, 0x32, 0x22, 0x34, 0x38, 0x22, 0x39,
  0x37, 0x22, 0x31, 0x30, 0x0a, 0x7b, 0x21, 0x5b, 0x61, 0x0a, 0x20, 0x22,
  0x36, 0x32, 0x27, 0x5b, 0x61, 0x22, 0x39, 0x31, 0x22, 0x39, 0x37, 0x22,
  0x34, 0x33, 0x22, 0x34, 0x39, 0x22, 0x39, 0x37, 0x0a, 0x20, 0x2b, 0x31,
  0x61, 0x0a, 0x7d, 0x0a, 0x22, 0x31, 0x30, 0x0a, 0x3e, 0x30, 0x61, 0x0a,
  0x7b, 0x21, 0x5b, 0x61, 0x0a, 0x20, 0x22, 0x5b, 0x61, 0x0a, 0x20, 0x2b,
  0x31, 0x61, 0x0a, 0x7d, 0x0a
};
unsigned int quine_bad_len = 77;

Translating this into bAdkOde is not as straightforward, but it’s not that difficult either. I removed the first line, and the last two lines from qhex.txt and then used a oneliner:

vivin@dauntless ~/Projects/code/perl/bAdkOde
$ cat qhex.txt | perl -e 'chomp($a=<STDIN>); map { print ">" . hex($_) . "[a+1a"; } \
   split(",", $a);' > qdec.txt

You end up with this snippet of bAdkOde:

>62[a+1a>48[a+1a>97[a+1a>10[a+1a>34[a+1a>54[a+1a>50[a+1a>34[a+1a>52[a+1a>56[a+1a>34[a+1a>57[a+1a>55[a+1a>34[a+1a>49[a+1a>48[a+1a>10[a+1a>123[a+1a>33[a+1a>91[a+1a>97[a+1a>10[a+1a>32[a+1a>34[a+1a>54[a+1a>50[a+
1a>39[a+1a>91[a+1a>97[a+1a>34[a+1a>57[a+1a>49[a+1a>34[a+1a>57[a+1a>55[a+1a>34[a+1a>52[a+1a>51[a+1a>34[a+1a>52[a+1a>57[a+1a>34[a+1a>57[a+1a>55[a+1a>10[a+1a>32[a+1a>43[a+1a>49[a+1a>97[a+1a>10[a+1a>125[a+1a>10[
a+1a>34[a+1a>49[a+1a>48[a+1a>10[a+1a>62[a+1a>48[a+1a>97[a+1a>10[a+1a>123[a+1a>33[a+1a>91[a+1a>97[a+1a>10[a+1a>32[a+1a>34[a+1a>91[a+1a>97[a+1a>10[a+1a>32[a+1a>43[a+1a>49[a+1a>97[a+1a>10[a+1a>125[a+1a>10[a+1a

Now all you need to do is copy this snippet into quine.bad (with one minor change) to get a bAdkOde quine:

>0a
>62[a+1a>48[a+1a>97[a+1a>10[a+1a>34[a+1a>54[a+1a>50[a+1a>34[a+1a>52[a+1a>56[a+1a>34[a+1a>57[a+1a>55[a+1a>34[a+1a>49[a+1a>48[a+1a>10[a+1a>123[a+1a>33[a+1a>91[a+1a>97[a+1a>10[a+1a>32[a+1a>34[a+1a>54[a+1a>50[a+
1a>39[a+1a>91[a+1a>97[a+1a>34[a+1a>57[a+1a>49[a+1a>34[a+1a>57[a+1a>55[a+1a>34[a+1a>52[a+1a>51[a+1a>34[a+1a>52[a+1a>57[a+1a>34[a+1a>57[a+1a>55[a+1a>10[a+1a>32[a+1a>43[a+1a>49[a+1a>97[a+1a>10[a+1a>125[a+1a>10[
a+1a>34[a+1a>49[a+1a>48[a+1a>10[a+1a>62[a+1a>48[a+1a>97[a+1a>10[a+1a>123[a+1a>33[a+1a>91[a+1a>97[a+1a>10[a+1a>32[a+1a>34[a+1a>91[a+1a>97[a+1a>10[a+1a>32[a+1a>43[a+1a>49[a+1a>97[a+1a>10[a+1a>125[a+1a>10[a+1a
>0a
"62"48"97"10
{![a
 "62'[a"91"97"43"49"97
 +1a
}
"10
>0a
{![a
 "[a
 +1a
}

The small change I had to make, was to add >0a at the beginning. If you run this bAdkOde program, it will print its source code as output. So there you have it. A bAdkOde quine, which proves that bAdkOde is Turing Complete. I have to thank Dave Cope for his quine tutorial, without which it would have been extremely difficult for me to write a bAdkOde quine!

Update (12/26/2009)

Dave mentioned that writing a quine only suggests that a language is Turing Complete, but not that it is. He suggested that I write an interpreter for Brainfuck which would then prove that bAdkOde is Turing Complete. That was actually my next project!

Update (12/26/2009)

I’ve been able to provide a direct translation of Brainfuck into bAdkOde, which proves the Turing Completeness of bAdkOde.

If you know assembly, then you know that a while is simply a set of statements wrapped with a conditional branch at the top and a backwards branch at the bottom (or in other words, an if with a goto at the end. A do-while is simply a set of statements with a conditional branch (at the bottom) that branches to the top of the loop. In fact, in assembly programming there really aren’t any for loops or while loops. These keywords are simply abstractions and syntactic sugar. In bAdkOde, you can implement an if with the existing while statement if you explicitly make it break out of the loop. For example, let’s say that we want to check whether the user entered the character “0″:

?a
-48a
# print a line break
"10
# if a is zero
{=a
 # print the string "zero"
 "122"101"114"111"10
 # set the a register to a non-zero value so that we can break out of the loop
 >1a
}

I knew there was a way to implement an if-else with just while statements but I didn’t remember exactly how. Then my friend and co-worker Juan reminded me that I needed two variables. In our case, we need to use two registers:

?a
-48a
# copy the value of a into b
>ab
"10
# if a is zero
{=a
 # print the string "zero"
 "122"101"114"111"10
 # set the a register to a non-zero value so that we can break out of the loop
 >1a
}
# if the top loop failed, it means that b (which holds the same value as a) is
# non-zero and so we can enter this block.
# if the top loop was successful, it means that b (which holds the same value
# as a) is zero and so we won't enter this block. Hence, the second block acts
# as an 'else'
{!b
 # print the string "non-zero"
 "110"111"110"45"122"101"114"111"10
 # zero out the b register
 >0b
}

Yes, quite ugly. But that’s what I’m going for!

The project I’ve just uploaded is called Sulekha, and is a text-based Markov-chain generator. You can check it out here. The comments for this journal entry are mirrored on the Sulekha project page, so anything you post here will be visible there (and vice versa). Let me know what you think. Oh, and it’s interactive so you can generate your own text-based Markov-chains too!

If any of you remember, I mentioned earlier that my “creatures” are nothing more than assembly programs. Each of these instructions (and parameters) translate into a bit pattern. Changes in the bit patterns lead to changes in the behaviour of the creature.

One of the instructions is a “reproduce instruction”. This prompts the creature to create a copy of itself, with possible mutations. The instruction has a parameter that tells the creature how many copies to create. During the course of the simulation, certain creatures evolved with the reproduce instruction as their first instruction.

My supervisor program (God program) runs one instruction of every creature during one cycle (sort of like an pre-emptive multitasking operating system). If a creature happens to reproduce during the current cycle, then the supervisor program will execute the child’s instructions as well in that current cycle. This led to an interesting situation. When the mutant that had the reproduce instruction as the first instruction reproduced, its child (if it didn’t have a mutation that changed the instruction) also had the reproduce instruction as the first instruction. So the supervisor program would run the child, and the child would reproduce with a similar offspring. This went on until a mutant that did not have a “reproduce instruction” as the first instruction, evolved. As you can see, this is what led to the population explosion. I corrected this problem by adding “sexual maturity” and “reproductive energy threshold” parameters to the creatures. Basically, a creature can reproduce only if it has been in existence for a certain number of cycles, and if its current energy is above its reproductive energy threshold. This got rid of the population explosion problem.

My simulations gave me some other interesting results. One of the instructions that I have is a MOV instruction. This instruction moves a creature from one cell in the two-dimensional array to another cell. There is a variant of this instruction, known as the MOVA instruction. In the MOV instruction, if the creature tries to move to an occupied cell, it will retreat to its original position. However, in the MOVA instruction the creature will try to kill (and subsequently eat) the occupant if the destination cell is occupied. I had created a creature that simply ate, reproduced, and moved to different cells. I noted that after many generations, this creature had evolved into an aggressive one, that would eat, reproduce, and move aggressively (MOVA) into other cells. That was rather interesting!

I also saw natural selection at work. When I corrected my population explosion problem, I made it so that the reproductive threshold of a creature was higher than its initial (starting) energy. Over the course of many cycles, I saw that the creatures evolved such that the initial energy would be very high, and that their reproductive threshold would be very low. In additon, their reproductive age was lowered. I thought that my creatures were having it too easy, so I modified my code to make reproduction a costly instruction. After running my simulation, I noticed the opposite! Now the creatures evolved such that the reproductive energy threshold would be much higher than their initial energy. It would seem that the creatures wanted to build up enough energy to where they would be able to reproduce successfuly.

There is also one very interesting behaviour that I noticed. I provide branch instructions in my instruction set. A creature can branch to any part of its code. In addition, I also have a Decrement and Branch instruction that is useful for iterative loops. One of my creatures evolved a clever strategy. It would decrement and branch into the middle of the branch instruction. When I analyzed the code, I noticed in doing so, the creature was performing a MOVA instruction in fewer bytes than writing an explicit MOVA instruction. It also had the added benefit of performing the MOVA instruction in an iterative fashion so that it could travel around the two-dimensional array. There was a reason for this kind of behaviour though. A creature consumes energy when it performs an instruction, and the energy consumption is proportional to its code size, so it is amazing, but not surprising that such behaviour could arise.

There is still more work that I need to do. I am thinking of giving my creatures some “memory” in the form of stack and RAM. They will have some Store, Load, Push and Pop instructions whereby they can write to and read from memory. Also, I am thinking of adding some more “registers”. Right now, the creatures have two count registers for performing iterative loops. My reason for adding more is this – I want the creatures to be able to act on the data in memory. For example, I can provide instructions that allow the creature to check the status of a particular cell, like if it is occupied, how much food it has, and so on. The creature can load data into the registers, and then use these registers as arguments for the cell checking instructions. This way I am hoping that my creatures will be able to evolve some rudimentary form of “intelligence”, or “intelligent” behavior. This will also increase my instruction set. Right now, if a mutation results in an invalid instruction, the creature dies when it tries to execute it. Actually, that reminds me – I had creatures that evolved with invalid instructions, but they had also evolved branch instructions that would jump over the invalid section of code!

Most of these complex behaviours aren’t that surprising when you consider natural selection… it is only err… natural that such behaviour should arise!

Well I guess that’s all I have for now. I might make a separate page for this project where I can describe this project in more detail. I’ll post more updates here after I run more simulations.

Now about the Artificial Life. I have written up some specs on an Artificial Life program. This is different from earlier ones. I am implementing the “creatures” like assembly programs. This code is their “DNA”. It describes how they behave. A “God Program” executes one instruction of each “creature” and moves on to the next. Sort of like a pre-emptive multitasking operating system. The creatures all live in a two-dimensional area of memory. They can reproduce, and there is chance of error during reproduction.

I think I was going about it the wrong way earlier. I was trying to describe behaviour through variables and through discrete quantities. Now, I represent each creature as a bit-pattern – exactly like an assembly program. I have instructions for moving, eating, moving and attacking, reproducing, and sleeping. In addition, I have some very basic branches and loops. So based on the bit pattern, the creature has a certain behaviour. Also, changes in the bit-pattern can cause changes in behaviour. They can be subtle, or drastic. At least, that is what I believe. I need to actually implement my idea before I can find out! My God program is essentially an operating system, and the “creatures” are tasks. There’s a little more to all of this, but I can’t write it all here. If and when I finish the program, I will make a separate page for it and describe it in detail.

I am thinking of calling this program “Eden”. Anyway, that’s all for now!