2 steps forward, 1.75 steps back

2 steps forward, 1.75 steps back

I’d planned to make an entry, just oh so chalk full of intriguing philosophical questions. In my personal project journal, this is entry 13, and it was going to be about the use of death in AI and digital life projects, specifically, my project. How so some ever never clever, I hit a snag.

My little subleq based creatures, which I call “figures,” live in a realm. At the moment, for testing purposes, the realm is only large enough to hold three figures. I wrote a figure by hand that copies itself, and sticks one random command, consisting of three numbers, at the end of the copy.

{P.SIZE, P.INNER_HEAD, 3, P.ONE, P.FIND_EMPTY, 6, P.N_BUFFER_SIZE, P.OUTER_HEAD, 9, P.N_THREE, P.OUTER_HEAD, -1}

If you’ve been following along, you’ll notice that unlike other figures written to this point, there isn’t a bunch of -1/s. Those -1/s were a way to make sure that execution of a figure would stop at that point. This time, I don’t want that to happen. I want the copy to have a random command that gets called, after it copies itself and puts a second random command at the end of that copy. This means that the first figure, only 12 numbers long, makes a child that is 15 numbers long. Then the child makes the grandchild figure that is 18 numbers long.

When I run it, most of the time I get the following output.

The size of the realm=3
Before:
Figure 0 at 0 Size=12
null
null
Threw the jungle
After:
Figure 0 at 0 Size=12
Figure 2 at 1 Size=18
Figure 1 at 2 Size=15

Hurray! all is well. Sometimes, the random commands generated change the size of one of the figures. Here’s an extreme example.

The size of the realm=3
Before:
Figure 0 at 0 Size=12
null
null
Threw the jungle
After:
Figure 0 at 0 Size=12
Figure 2 at 1 Size=1242
Figure 1 at 2 Size=15

Here’s an example of the child, rather than the grandchild figure being changed.

The size of the realm=3
Before:
Figure 0 at 0 Size=12
null
null
Threw the jungle
After:
Figure 0 at 0 Size=12
Figure 2 at 1 Size=18
Figure 1 at 2 Size=64

And here’s one that pleases me. The first figure is increased in size. The change must happen because of something that the child or grandchild figure is doing. That figure cannot write to itself, ever. the fact that its size changes, proves that there is interaction happening between the figures, even when there are only three of them.

The size of the realm=3
Before:
Figure 0 at 0 Size=12
null
null
Threw the jungle
After:
Figure 0 at 0 Size=18
Figure 2 at 1 Size=18
Figure 1 at 2 Size=15

I ran this test a bunch of times, caught up in what was happening. Of all the times I ran it, I only saw a figure get smaller once.

The size of the realm=3
Before:
Figure 0 at 0 Size=12
null
null
Threw the jungle
After:
Figure 0 at 0 Size=0
Figure 2 at 1 Size=18
Figure 1 at 2 Size=15

See that? One of the children killed the original figure.

All to the good, all the sort of behaviors I wanted from the system. Still, this test runs each figure in turn. Each figure’s entire program runs until finished. I’d much rather that each figure got one command, and then the next figure got to do one command, and so on. I’ve been planning this since the beginning of this project, so I made the changes to make them take turns, and ran the test again.

The size of the realm=3
Before:
Figure 0 at 0 Size=12
null
null
Threw the jungle
After:
Figure 0 at 0 Size=12
Figure 2 at 1 Size=15
Figure 1 at 2 Size=15

Wait… That’s not right… that’s not right at all!

I did all kinds of tests—increase the size of the realm, increase the number of turns, changed the code so that each figure would search for an empty slot in a random direction—but no matter what I did, all the children came out at the same 15 number size. After I don’t know how long, I gave up for the night, and restored the code from a backup copy.

Less than five minutes after giving up, I suddenly realized what the trouble was. If they each get one command at a time, then the child figure copies its memory into its buffer before the parent gets a chance to write the random command at the end.

Little bastards! Doing exactly what I told them to! Don’t they know any better?

Instead of tearing apart the overall system, I need only rewrite the original figure.

I haven’t tested this theory yet, so give me a few and we’ll see whether or not I’m right.

The size of the realm=3
Before:
Figure 0 at 0 Size=24
null
null
Threw the jungle
After:
Figure 0 at 0 Size=27
Figure 1 at 1 Size=30
Figure 2 at 2 Size=33

Believe it or not, that is working the way it should. It’s a bit harder to follow, as the new seed, or starting figure, changes its own size, and so do the children.

{P.N_SIZE, P.MOVE_INNER, 3, P.N_THREE, P.INNER_HEAD, 6, P.SIZE, P.MOVE_INNER, 9, P.SIZE, P.INNER_HEAD, 12, P.N_ONE, P.FIND_EMPTY, 15, P.N_BUFFER_SIZE, P.OUTER_HEAD, 18, P.THREE, P.MOVE_INNER, 21, P.THREE, P.INNER_BOARD, -1}

The figure appends a random command to itself, before copying, finding an empty slot, and writing the result. Then, it cuts that random command off its own end and starts over. While a figure is cleaning itself up, there is enough time for the child figure to find an empty slot and copy itself. While I was at it, I changed the direction they search for empty slots so that the newest figure is lower than the figure that is its parent. I went through and increased the number of commands run for the test by one, over and over again, watching to make certain everything happened as I hoped. It did, they did, and we can now move on with our lives.

They aren’t really behaving how they should, simply because they weren’t designed to fill every available slot. To make more room, some of them will have to die. It’s a grim task, but next, I must bring death into the realm.

Comments are closed.