I started working on this project in December. Months later and, for certain values of the word “done,” it’s done. All this time, I’ve been building tools to make implementing various and sundry experiments easy, or at least, easier. Now that I have my tools, let’s play with them.
…
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!
…
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.
…
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?
…
Podcast: Play in new window | Download (Duration: 10:34 — 5.7MB) | Embed
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.
Podcast: Play in new window | Download (Duration: 7:04 — 4.2MB) | Embed
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.
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.
…
Have the output of a test run.
memory={-6, -14, -1, -1, -1, -1, -1, -1, -1, -1, -1}
size=11
Size=8
Buffer size=3
memory={-1, -1, -1, -1, -1, -1, -1, -1}
buffer memory={-6, -14, -1}
…
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
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.