Much of my thinking on artificial general intelligence has been oriented towards evolutionary programming and related approaches. This approach makes sense when one thinks about things humans do which readily map to programs. To drive a car to work we might go out of the house, into the car and drive to the end of the street. IF we see traffic we wait; ELSE we proceed. IF we are near the end of the next street we start to slow down, and so on. In this view it makes sense to think about automatically generating such programs. Generate a program; test it; improve it; compare it to others; etc. We could call this DIRECT evolutionary programming.

In his book On Intelligence Jeff Dawkins presents some fascinating ideas about his view of what is going on in the cortex as a guide to an AGI approach. Half way thru Dawkin's book I was led to an idea that I plan to explore. It could be called "INDIRECT evolutionary programming" or "bias for action".

Babies don't know much - but they appear to have a bias for action. Their arms and legs flail around and they make seemingly random verbal sounds - "baby talk".

The idea is to give the AGI a strong bias for action, a large memory and an optimizer. It would work something like this:

The AGI would perform lots of actions mainly at random and record the results in a large memory. For example in a Go world an action sequence might be Eye Up, See Black, Eye Right, See Empty, Play Stone. That pattern would be added to the large memory. Lots of actions would be performed and added to memory. A reinforcement learning algorithm would cull the patterns and actions that lead to good scores. We can think of the memory as a very loose "program" that is easy to modify, robust, and of the flat Brooklyn Code style. On another thread an optimizer would continually work to simplify the "program" by combining similar patterns, looking for patterns in the patterns, etc.

This approach is somewhat the opposite of a direct search for "Occam programs". Our instinct to search for Occam programs is based on our experience in human programming or engineering in general where we aim straight for a small efficient solution. The proposed approach is essentially the reverse. We begin by building an extremely large non-optimal program of the Brooklyn Code variety and then gradually optimize it.

Posted 8/22/07