Kinetic Code

Friday, August 12, 2005

The vision

So having had the brief description of the system in the last post, now it is time for a more in depth description of my (current) long term goal.

But first a bit of background on some terminology I am going to use.

The bowl, (which contains the soup...), is a virtual machine composed of many very tiny processors called areas. I should have called them chunks or something. A program is composed of many areas, with one special area called the owner. All the areas reference that owner area, and can access other areas with the same owner but can't generally access other areas with different owners.

So what does the system do. The system starts with a single small program defined in it areas. This program just initially copies itself to the other areas of the bowl. Then the programs differentiate themselves based on their area number (each is unique). Having done that they are ready to start doing a few different things.

The first is to select other programs to work with and possibly a leader. A leader is a program that coordinates who is allowed to output to the real world and who gets what reward (there may well be sub-leaders as well). So only outputting programs need to select a leader. The others select which programs they will accept inputs from and give output to (they will also pass some reward on). So at the end of the setting up stage we have a network of programs that are set up to process whatever is going to put into the system and perform the most basic tasks.

At this point the programs start experimenting with themselves by adding in small bits of code or altering parameters. So they differentiate themselves by only a small amount.

We shall assume it performs some tasks for a while, and the programs perform some statistics on the tasks they do and reward they get. They then get a chance to over-write other program, those having accumulated more reward having to spend it to get the areas inhabited by other programs.

There are reasons for all the little foibles of this system, which I shall explain in later posts.

"How close am I to getting this working?", you ask. Well not very, the bowl and areas are sorted modulo bugs of course. And I am starting to get the leader bit working and making the reward system work. But them forming a network and tweaking themselves will take a while.

Coming next: The interface to the bowl and a new sourceforge release

Technorati tags


and

Wednesday, August 10, 2005

The first post

And a long time overdue. I should have started this project diary an age ago when I started my project. So I have a lot of catching up to do.

The project this is a diary of is called codesoup. And is my vision of a future posibility for computation. When I started it, it was a project that relied on the power of evolution TM to drive it to new and wonderfully creative feats of coding. Hence the projects title, a reference to the chemical soup theorised to have created the first replicating entities.

Now, however, after a brief bit of experimentation and a lot of reading of algorithmic complexity papers and nature/nurture debates, the focus is on designing virtual machine code that has a fair amount of complexity built in. But which can change and move, hence kinetic code, mainly because dynamic is already wildly overused. But I am getting ahead of myself.

A relatively concise description of my vision is the following. A computing system where humans code a beginning program that develops into an adaptive goal based system where the competition for computing space is governed by selective pressure. The method for determining which program gets to survive a competition for space is governed by a property called energy, this is given to a program by an external rewarding force and will be distributed by economics.

A few points worth remembering-
  • The only parts that are fixed are:

    1. the method of deciding who gets the space (when a program trys to overwrite another)

    2. the rewarding for performing a task

  • The rest of the system including messaging between programs and the economics has to be built like an OS by a human

My diary policy will be generally not to allow comments, mainly to encourage discussion to go to athe projects sourceforge email list .

Technorati tagging will be generally and when appropriate. I shall also do this once. But I dislike the term so look for codesoup if you want to be sure of finding this.