They’re starting to wriggle

I did a test where I had the code create a figure that was 36 safe random numbers long. A “safe random” number is a random number in a range equal to the lowest port number, and the memory array’s length. Port numbers are negative. 36 numbers is a max of 12 commands, unless the figure loups.

Getting computer code to pretend it’s a live means you have to make the operations safe. What would normally be an error or shutdown the program has to be handled so that the system keeps going. One of the things to watch for are infinite loops.

An infinite loop isn’t always a problem. In a way, life is an infinite loop, or at least within certain conditions it is. But a program can get stuck in a tiny infinite loop that does nothing.

It would be nice to test for such things ahead of time and trim them out of the way, but that’s called the halting problem, and it’s been shown to be unsolvable. I used the usual trick and put a counter in and had the program stop if more than the maximum number of allowed commands took place.

If commandCount>1024
stopAlready();

For testing, I set it up to give me a message when it got that big. I also looked at the size of the figure before and after, and the number of commands.

I was surprised how many programs just ran fine.

There are a couple of beeps and messages left over from earlier testing. They’re “bad address” messages mostly. They’re handled by just letting the given figure stop running, leaving the overall system still executing. Later, that figure gets reset and runs its code again. What were errors are treated as reset and rerun commands. Note that reset doesn’t put the figure back to the way it was—whatever numbers have changed are still different the next time it is run.

Even including those “errors,” most programs just ran their code and stopped, not even spitting out the old error messages.

Most of the time, the random figures would execute one to three commands and then stop. Sometimes, even those short programs changed the size of the figure. I saw one program execute two commands, and double in size.

Now and then, I would hit an over large loop. I say “over large” because some of those loops may have been very large. Say, 1050 commands, but still not infinite.

A bit less often than the over large loops, I saw that a program had run for 15, 16, 20, 30, 40, and once, 88 commands.

Most of those sent out the old error messages. Those aren’t error messages anymore, and I’ll have to comment them out next. But even with those as errors, the 88 command long one ran fine.

Programs need to be able to form loops, and step back out of them again. The figures, when generated with safe random numbers, have formed loops that aren’t trivially small, and which are not infinite.

I get to implement more ports next, which will change the probabilities. The more ports there are, the more likely code generated by safe random will be likely to be using one of the ports. If you want your figures to be likely to “think about it,” meaning do some calculation, you can adjust their length.

If there are 50 ports, then if your figure is 50 numbers long, then half of the numbers safe random provides will be valid addresses, and not ports. If you wanted 90 percent valid addresses, and there were 50 ports, your figures would have to be 450 numbers long.

Right now, each port maps to one address. If I want to encourage the use of a given command, I can assign a range of values to that command. I can use the same approach to be able to make calling of a given command much less likely on average. That gets into tweaking parameters, which I hope to keep to a minimum; but it’s an option if they have trouble keeping meta stability.

Mind you, I’m snagging a trick from Tierra, and seeding the population with things that already replicate.

Once all the ports are implemented, I might take a day or two and see if self-replication might emerge from a few thousand randomly generated programs… just for fun.