Category: digital organisms

Trembling on the verge

Trembling on the verge

I’m about to archive the current state of this project as figures0.1. 0.0 was just far enough so that a program could reproduce itself, and add a slight mutation. This version has every last port implemented. That is, the little programs, or figures, can do everything I want them to be able to do.

They can read or write from themselves and one another. They can write random numbers that are safe. The random values produced are all valid addresses or ports.

They can also cut and paste to and from themselves and each other. Pasting is like writing, only the values are added, inserted into the place they are writing to, instead of being written over what’s already there. Cutting is like reading, only the elements being read are removed from where they are being read from.

The very last thing I had to test was the jump command, port -50. If a program reads, writes, cuts, pastes, or even moves inside of another figure, that figure gets a port that connects to the figure that did the reading, writing, or what have you. This gives the figures a way to react to any figure that is doing something to it. The only way to escape from the retribution is to change where you’re living, jump.

Here are a couple of figures. The first one just moves it’s read write head inside of the second one. The second one then cuts out the entire memory of the first figure, effectively killing it.

First figure: {P.N_THREE, P.MOVE_OUTER, 3, 0, P.FIND_EMPTY, 6, /*0, P.JUMP,*/ -1, -1, -1, -1, 1, 2, 3, 4, 5}
Second figure: {P.OTHER_SIZE, P.OTHER_BOARD, -1, -1, -1, -1}

Here’s what happens if we run them.

The size of the realm=3
Before:
slq buffer size=0
slq2 buffer size=0
Figure 0 at 0 memory={-3, -32, 3, 0, -17, 6, -1, -1, -1, -1, 1, 2, 3, 4, 5}
null
Figure 1 at 2 memory={-38, -45, -1, -1, -1, -1}
After:
slq buffer size=0
slq2 buffer size=15
Figure 0 at 0 memory={}
null
Figure 1 at 2 memory={-38, -45, -1, -1, -1, -1}

In that run, the jump command is commented out. If we uncomment it…

{P.N_THREE, P.MOVE_OUTER, 3, 0, P.FIND_EMPTY, 6, 0, P.JUMP, -1, -1, -1, -1, 1, 2, 3, 4, 5}

… the first figure is able to save itself.

The size of the realm=3
Before:
slq buffer size=0
slq2 buffer size=0
Figure 0 at 0 memory={-3, -32, 3, 0, -17, 6, 0, -50, -1, -1, -1, -1, 1, 2, 3, 4,
5}
null
Figure 1 at 2 memory={-38, -45, -1, -1, -1, -1}
After:
slq buffer size=0
slq2 buffer size=0
null
Figure 0 at 1 memory={-3, -32, 3, 0, -17, 6, 0, -50, -1, -1, -1, -1, 1, 2, 3, 4,
5}
Figure 1 at 2 memory={-38, -45, -1, -1, -1, -1}

Okay then, figures0.1 is done. I’m glad, as the next bits of development will finally start to get into the fun stuff.

And the baby has a baby

And the baby has a baby

When I started posting about this project, I just dove in. Eventually I’ll have to lay out exactly what I’m working on, and how I’m approaching the development of my artificial life forms. That will take some time. For now, have yet another post wherein I entirely fail to explain what’s going on.

Over the weekend, I finished coding the Figure class. It only took 1500 to 1700 lines of code, depending upon how you count and what you count. I still have much testing debugging and documentation to get done before I can finally move on to the interesting parts.

A few days ago, while testing one of many little pieces of the project, I saw the first little program that was produced by the system, instead of hand written by me, reproduce itself, I’m going to paste in the text from my journal. Note that each program copies itself, and adds a small mutation to the end of the child program. The longer the program, the younger it is.

Friday January 19, 2018

2:18:AM

First time I ran a figure I didn’t write.

The size of the realm=3
looking for neighbors.
Going up.
nobody new around.
Reading from out there.
Running baby.
looking for neighbors.
Going up.
party at 0!
Reading from out there.
Figure 0 memory={-4, -17, 3, -9, -13, 6, -8, -19, 9, -3, -19, 12, -6, -18, -1, –
1, -1, -1}
Figure 2 memory={-4, -17, 3, -9, -13, 6, -8, -19, 9, -3, -19, 12, -6, -18, -1, –
1, -1, -1, 3, 17, -14, 18, 15, 22}
Figure 1 memory={-4, -17, 3, -9, -13, 6, -8, -19, 9, -3, -19, 12, -6, -18, -1, –
1, -1, -1, 3, 17, -14}

See that? Baby had a baby!

I love the smell of code in the morning

I love the smell of code in the morning

I need to make a couple of notes before I forget.

I went through and put in code to set b to 1 or -1 on the methods that needed it. I was going to have write and paste, both inner and outer return a -1 if they were called while the buffer was empty. However, I changed my mind. Instead, the outer commands return -1 when a figure tries to write or paste to itself with the outer head. The same thing will happen with read and cut. As it happens, that means that inner write and inner paste never set b to -1. I went ahead and had them set b to 1, just for the sake of consistency.

Meanwhile, in move inner, b is set to -1 if the method tries to move the inner head further than it can go, and otherwise sets b to 1. That gives a figure a way to tell when it has reached the top or bottom of the figure. Read commands also set b to -1 if a read command is sent while the head is at the end of the figure, one spot further than there are numbers to be read.

I need to make sure that any outer commands, like read cut write or paste, set the otherHead field of the figure being read from or written to, to be the address of the figure that is doing the reading or writing.

I’ve still got several outer head commands to implement, and I’m way behind on comments. I actually think I’ll go ahead and finish implementing the remaining ports before I catch up on the docs. It shouldn’t, judging by the methods I’ve already created, take too long. With a combination of cut and paste, and find and replace, I can adapt the methods I’ve already implemented to do what they do, only to another figure, instead of the one that is calling the outer head ports.

I have no clue how long catching up on the documentation will take, but I don’t want to go further without getting that done. There’s just too many little details that could get lost if I don’t take care of it soon.

Meanwhile, last night, I tested setting one of the slots in the realm’s population array to null. It worked. I ran it a couple of times, but stopped when I realized that I was making orphans. The one figure would write out a child copy of itself, add a slight mutation, and then the parent figure got deleted. The system is very far from creating anything that would count as living, but it still made me feel just enough guilt to make me stop screwing around and move on.

Okay, that’s where I am, and where I’m going.

I got the addresses handled in what’s there so far. I made sure the outerWrite command set the target figures’ otherAddress field to be the address of the source figure.

While I was at it, I changed some of the test code messages, so directions up and down are reversed from before. I just picture 0 at the top of the array, so adding is going down to me.

When a method needs to see if the outer Head is pointing at the source figure, it should test the addresses. It was using the name field, but I might switch that to a string or some other object. I changed that too. That’s why I did all this in the morning; I had too much that I might forget to do if I didn’t get it done.

If x==address

Got an episode to get done.

Mutant bouncing baby bits

Mutant bouncing baby bits

It’s Saturday night, and I’ve got some coding to do. I’d really like to get a figure to self-reproduce tonight, but I don’t know if I can pull it off or not. Last time, in the middle of creating the realm, I realized that there was and is some stuff that needs doing with the ports and methods I’ve already created. The figures could use some feedback on how a given operation has worked.

It’s really easy to setup. I can set b to zero or less for one result, one or higher for the other. It actually doesn’t matter, since this happens from a set command. The value I give to b will only be used to choose one or the other branch, and won’t be saved. I’ve already got the test code in place, and moved b to a global scope for the Figure class. I’m thinking of moving the other internal values for what is, at the moment, the run method to the global scope as well. Right now, it’s all about the set method, but I have no idea what future implementations or extensions might need or want to do. I think it’s best to go for maximum flexibility, especially for the node system which I’ve yet to talk about, let alone implement.

Ports are used for special commands, Nodes are used to add new ports and abilities. The goal is to create a tunable emergent system. I don’t just want digital life; I want digital life that can solve problems and do tasks for me. It’s artificial life that is also artificial intelligence.

Read More Read More

Ep 112: Evolving neural networks with polyworld

Ep 112: Evolving neural networks with polyworld

Evolving neural networks with polyworld

Figuring out exactly what structure of a neural network could capture intelligence is a complicated problem. Why not let evolution do it for you? Today we look at Polyworld, where they did and are continuing to do that very experiment.

Here’s a talk on polyworld and some of their results.

Using Evolution to Design Artificial Intelligence

Ep 103: Tierra, bits bytes and life

Ep 103: Tierra, bits bytes and life

Tierra, bits bytes and life

In the early 1990/s, a biologist named Thomas Ray created a computer program that acted like a computer infected with many little programs. He called it Tierra, Spanish for “Earth.” The little programs could, and did, mutate, self-replicate, and evolve in strange and wonderful ways.

Here’s the home page for Tierra.

Tierra home page

Here’s a good article about Tierra.

Artificial Life – Tools Ideas Environment

And here’s a nice video on the Tierra system, and the story behind its creation.

Project Tierra

Ep 102: Core Wars

Ep 102: Core Wars

Core Wars

In 1984, the game Core Wars was written and introduced to the public. Contestants write programs in a special language called redcode, and attempt to halt or overwrite the other programs in order to be the last game standing.

Here’s a beginner’s guide to redcode

The beginners’ guide to Redcode

Here is a link to a page that has html versions of the original scientific American articles that introduced the game.

A. K. Dewdney’s Scientific American Articles on Core War

Here are a couple more links to pages about the game.

Core War

Corewar – the Ultimate Programming Game