Category: test

It was a clever notion, but not a good idea.

It was a clever notion, but not a good idea.

It’s been several days since I noticed that my oh so very clever notion wasn’t actually a good one. I’ve been developing my little subleq creatures, called “figures,” layer by layer. There is one more layer to go, and I had what I thought was a brilliant way to implement it. That is, until I tested the new layer against the old version and saw that the same exact run, with the same exact results, was taking up to 59 percent longer!

Read More Read More

Making it simple isn’t simple

Making it simple isn’t simple

Let’s get started.

Putting together the nodes and handlers is going to be somewhat painful, and slow. It might be a bit more fun, along with giving me a way to test the general concept and implementation, if I implement the handlers to help me do a particular experiment or two. There will be no getting away from days of going through, method by method, bit by bit, but this should be a much more interesting way to get started.

Read More Read More

Debugging death

Debugging death

In episode 144, I oh so casually mentioned that I was getting some runtime errors. They don’t happen in every run, but the fact that they happen at all is a problem. My artificial life system will eventually be running for days at a time as I do different experiments, and I can’t have these errors causing my system to halt.

What does one do when one sees output like the following?

Read More Read More

Ep 144: Emergent self-replicating software from my experiments

Ep 144: Emergent self-replicating software from my experiments

Emergent self-replicating software from my experiments

In the previous episode, I provided a description of “Amoeba.” In this episode I use “Figures,” which is my own experiment with digital organisms and artificial life, to repeat the results of Andy Pargellis’s Amoeba experiment, with a few differences. I also give the most detailed explanation of my subleq based system to date, as I compare and contrast it with Tierra and Amoeba.

Here are links to episodes relevant to today’s episode

Ep 143: Emergent self-replication with Amoeba

Ep 103: Tierra, bits bytes and life

Here’s a blog post that describes what subleq is and how it works.

The prime, and only, directive.

Here’s a video that provides a decent introduction to artificial life and digital organisms.

Artificial Life

Ep 139: de facto fitness functions and unexpected early evolution

Ep 139: de facto fitness functions and unexpected early evolution

de facto fitness functions and unexpected early evolution

When people talk about their artificial life computer simulations, they often say that there is no fitness function—no bit of code that decides which bit of software lives, dies, or reproduces. Even if it isn’t happening on purpose, the design of the overall system can still cause a de facto fitness function, and behaviors you didn’t expect, and perhaps, really didn’t want. It has already happened to me and my figures, despite using only a small test population of two or three individuals.

Here’s a link to episode 112, about Polyworld.

Evolving neural networks with polyworld

Here’s a link to a talk about Polyworld. The interesting bit where their de facto fitness function caused problems is at 30 minutes and 25 seconds.

Using Evolution to Design Artificial Intelligence

The only bug was in my Brain!

The only bug was in my Brain!

Previous post in topic
Next post in topic

In the previous post, I talked very briefly about a one instruction set computer. I didn’t go into details because I hadn’t had a chance to play with one yet. Well, I’ve played with it, and it isn’t as difficult as I was making it.

The one command I’m playing with is called subleq. That short for, “subtract and branch if less than or equal to 0.” Don’t worry if this doesn’t make sense yet; I’ll explain in painful detail in future posts.

B=A-b
If B

Build your own computer

Build your own computer

Next post in topic

We’re fast approaching topics like evolutionary computation and artificial neural networks on the show. Unless something crops up that is just too interesting not to make an episode over, we should get started with that by episode 89. It has been a long time since I last considered these topics, and I’ve been looking forward to finding out what new tricks have been found since.

My favorite approach is genetic programming, as described by John Koza. Mind you, after the recent episodes, I’m more aware than ever of its limitations, but it still strikes me as a rather elegant approach.

In genetic programming, you start with an initial, usually randomly generated, population of small computer programs. The programs are tested and evaluated, and each one is given a fitness score, based on how well each one is doing on the given problem. Some portion of the population that has done relatively well on the given problem, are perturbed—mutated and perhaps combined in an analog of sexual reproduction—to form the next generation of programs. The new population is sent through the whole process again, and the loop continues until one or more of the programs in the population are solving the problem to your satisfaction. Either that, or they entirely fail, and you have to back up and figure out what’s going wrong.

In gp, each possible command is called a “node.” The programs are composed of nodes that are specific to the given problem, tied together in a way that makes sense. I’ve always wondered if there might be some set of nodes that could, at least in theory, solve any given problem.

The set of all possible problems that can be solved by a computer is infinite, or as close to it as makes no practical difference. Even so, it turns out, the set of commands needed to solve any problem that can be solved by computer can be very small. In fact, if you’re unconcerned with how difficult it is to write a program, you can actually solve any computable problem with just one command.

Introducing the “one instruction set computer.”

A “one instruction set computer” or, “oisc,” is a method of computing that uses only one command. There are several approaches. Some of them use mathematics, and at least one, uses a command that simply moves data from one location to another. The oisc approach is most often used as a method for designing computer hardware, but we might be able to adapt it for evolutionary computation.

I’ve always wanted to be able to design a computer, at least conceptually—to be able to go from simple bit manipulation, all the way up to something that could run an arbitrarily complicated piece of software, like word processing or games. This is the first time that particular goal has been in sight. Before attempting to use such algorithms for evolutionary computation, I need to familiarize myself with how such things work.

So, let’s make a computer!

This would make far too many far too miserably lengthy and dull podcast episodes. Instead, I’ll blog about it.

I’ve no clue how long this will take, or if I’ll even finish. I make no promises, but it’s an interesting experiment.

Next post in topic