Skynet v 0.1

[AlexH]

Hi everyone, thanks for providing such a great resource in LAVA, I am very glad to see it back again.

It occurred to me that VI scripting would be a great way to try making programs that build themselves using a sort of genetic algorthm.

Something along the lines of:

     Place random block diagram objects.

     Wire up at random

     Can vi run? If not discard, if so, create many child VIs with slight modifications, or wholesale copying of parts of block diagram (c.f. gene duplication).

     Apply some sort of fitness function, perhaps testing for successful interfacing with instruments, or speed of execution.

     Select 'fittest' VIs, and repeat.

It would be very interesting to see what came out of that. I don't know how easy it would be to implement, or whether you would need some sort of DNA style encoding of the block diagram to work with, but it looks like a fun challenge for someone!

Cheers,

Alex

Edited July 17, 2009 by AlexH

[Francois Normandin]

Interesting challenge indeed. You'd have to set a particular goal if you want to define criteria for deciding which VI is the fittest. In nature, you'd have VIs fighting for local resources and the one that takes enough to sustain themself would perpetuate, but that seems difficult to do if starting with an empty diagram.

I'm not sure that such a challenge would attract a wide public as scripting is still on the fringe of LabVIEW programming. Surely enough, it would be real fun to watch!

[AlexH]

It might be reasonably easy to start with an existing VI and simply try to optimise the speed of execution for example.  I've a feeling that would end up with highly parallel layouts that are hard to come up with by yourself.

[jcarmody]

Isn't this how computer viruses began?

[AlexH]

Isn't this how computer viruses began?

I think that was more of a case of intelligent design...    

[PaulG.]

... start with an existing VI ...

I liked your first idea better. That's the rub when writing software that attempts to imitate "evolution". A lot of evolution software programs have been coded but invariably the biases of the programmers find their way into the code. You just did it yourself. Which existing VI? The VI that starts off with just a while loop, or an existing VI that starts out functioning like an amoeba?

[AlexH]

I liked your first idea better.

Me too.  What is particularly interesting about using Labview is that it would be very easy for the program to acquire senses!  (Well maybe not smell just yet, though if anyone has a mass spectrometer driver lying around its not out of the question).

Alex

[hooovahh]

I like this idea. I think we could do some testing with a small subset of rules. Say you must start with 2 booleans, and a numeric indicator. Then have it randomly write code, dropping primitives and wiring them up, until the state of the 2 booleans gives you the numeric results you want. To make it easy you could say OFF OFF = 0, OFF ON = 1, ON OFF = 2, ON ON =3. Now having intelect we know the easiest (or at least an easy) way to write a VI that does this, but for it to do it randomly would be interesting.

How long would it take? How big would it be? Then you could try the survival of the fittest idea, where the smallest fastest VI that performs the task properly, is the one that gets modifed to do a similar task. Maybe add a 3rd boolean.

But even this simple task may take a very long time for a successful VI to be created. I imagine alot of system resources too. It would be nice maybe to have an indicator saying how many VIs were able to get OFF OFF = 0...now that I think about it maybe one boolean is a better start.

[AlexH]

If you let it use scripting VIs then it could become self-replicating!  That would certainly provoke a not entirely welcome competition for resources!

[PaulG.]

If you let it use scripting VIs then it could become self-replicating!

First, scripted VI's running amuck ... then Grey Goo.

[hooovahh]

When I took microcontrollers 1 and 2, I remember the professor telling us over and over again never to modify your own code while the program was running. By this I mean you have a set of instructions that start at 0x1000, and as the program ran you shouldn't use any thing from 0x1000 to the end of your program, as temporary memory space.

I always thought he told us not to do that because you would be changing how the program would operate after the first run, but now I realize he didn't want us creating code, that could become self aware.

[NATE]

I admit I don't know much about genetic algorithms, but I remember seeing something on the Discovery Channel a couple of years ago about an application that was written to attempt to demonstrate evolution. Basically he created a bunch of blobs on the screen. I think each blob had a maximum life span, but could die earlier due to lack of nutrition and maybe attack from other blobs, can't remember. The blobs could move, always seeking out food particles. I don't think the blobs mated, I think once they acquired enough food they could asexually have offspring. Random permutatations were allowed to be introduced each time an offspring was born. In theory, the permutations that were beneficial increased its likelihood of survival. But what I don't know is if these "random permutations" were controlled or if it literally allowed any bit in that object's memory space to be modified. This seems highly unlikely because then you would end up with a vast majority of the offspring being "uncompilable". But every so often, you might have an evolutionary leap, and the child might be able to move 10x as fast as the parent, or defend itself better, or have a longer lifespan, or whatever.

Very interesting idea, but the practicality of it seems nearly impossible. And even if it was possible, VI Scripting isn't terribly speedy, so I'm guessing a LabVIEW implementation of this same type of simulation would run at a fraction of the speed of C or C++, and there's the problem that LabVIEW doesn't really give you the ability to modify any memory address.