When more to do means done sooner

Have you ever put something down, only to forget where you put it? Suppose you know for certain that you left whatever it is in your room. It will take a certain amount of time to search your room in order to find the thing. What if you can’t remember which room of the house you might have left it in. Now, instead of searching your room, you have to search the entire house. Logically, you’d expect that searching a larger area would mean the search is likely to take longer. So imagine my surprise when my digital organisms consistently found better answers much faster when doing a larger search.

In my first post about the dorg, I explained how they have three parts—memory, interpreter and ports. The ports are usually slightly different for each experiment—each different problem the dorg are attempting to find a good answer for. To test and debug, I’d given the dorg a very simple game. All they had to do was call one port, the good port, and avoid calling the other, the bad port. They’d do that for 10,000 cycles for each round, providing a best possible score of 9,992, and a worst of -9,992. There were a handful of other ports implemented. They were left over from an earlier testing phase, when I was making sure that the dorg could do things like loop, perform operations on numbers, and branch back out of the loop based on the results. I’d thought about removing all but the good and bad ports, but I’d thought that would be too damn easy. Such a small search space would mean they’d find some pretty good answers pretty darn quickly, and wouldn’t be a decent test of things like crossover and mutation.

It’s typical of evolutionary computation that the dorg never got the best possible score, but they got up to 9,001. Not too shabby, and it was enough to let me know that the system worked more or less as it should. The results meant I was done with testing and ready to move on to more interesting experiments. I rubbed my hands together, and got ready to make a set of ports to work on the next challenge.

I was thinking I wanted to redo the ports I’d already made, so I took them out, leaving only the good port and bad port behind. Just for fun, I ran the game again. I wanted to see what kind of score they’d get, and how quickly. Only, they did a miserably bad job of it.

The following graph tracks 100 rounds. It shows the best score any dorg got, along with the average and half average scores.

And that was the best run I got. Compare that to the worst run when all the ports were there. Same as before, 100 rounds.

And here was the best run.

It wasn’t just some fluke, some extra lucky run with all the ports there. Having more ports to search through gave much higher scores much quicker. What is going on?

The dorg are based on a transport triggered architecture. That means that all calculation and logic operations are ports. Without those ports a dorg isn’t a little computing machine anymore; it’s just a set of numbers that the interpreter runs through with no branching or looping of any kind. It struck me that that could be the problem, specifically that without a port that could allow the dorg to loop, there were no easy to find high scoring approaches. Either they fill their code with the good port address or they don’t. With a port that lets the dorg change which command is being interpreted next, basically a go to command, there are many ways to score well right out of the gate. To test the notion, I put a jump port I’d made back in. This time, this graph is 100 rounds, with a good port, a bad port, and the jump port.

And there it is, almost as good as before. Once I’d plumbed the depths of this little mystery I took a look at the ports I’d made. I can’t tell you what I was thinking—why I thought just tossing what I’d done so far would have been a good idea. The ports were and are fine. I put them back in and implemented a few more, just to be certain each individual dorg is Turing complete, that it will be able to calculate most anything it needs to calculate, and build whatever program flow is required.

If we return to your house, and your missing item. Having the entire house to search could go quicker than searching your room, if one of the rooms in your house has a useful tool for searching… a metal detector or something… You know what, forget the analogy, just sometimes, more is better.