On 3/12/07, Eugen Leitl <[EMAIL PROTECTED]> wrote:

The first and biggest step is to get your system to learn how to evolve.
I understand many do not yet see this as a problem at all.


Indeed!

I don't understand why you moved away from it (it's the only game
in town), but if you have a document of your conclusions to share,
fire away.


I concluded it's a dead end for AGI, so I discontinued work on that track
and didn't bother writing up anything like formal documentation, but it
isn't useless, has been used for some narrow AI problems, so to summarize my
conclusions on how to maximize the chances of getting results out of it:

The big issue is that evolution by default takes time exponential in the
amount of information you want to generate. You wouldn't think so because
it's hill climbing so you get to build step by step, and biological
evolution did that in polynomial time, but in general the local optima get
you. I was surprised looking at the graphs of some of my runs (the ones with
fewer complicating factors) just how regular the exponential curve was, each
big step taking twice as long as the previous one to find, each triggering a
string of little steps rapid at first but each little step also taking twice
as long as the previous.

That means don't sweat constant factors of machine efficiency. A factor of a
hundredfold here or there doesn't matter. Program in Python if that's what
you're most productive in, you can always rewrite in Fortran later if you
like but for the foreseeable future the bottleneck will be your time, not
machine time.

The important thing is to beat, or at least avoid as much as possible, that
exponential curve. Create ways to find building blocks, or ways to find such
ways.

Common wisdom is representation needs to be flexible like protoplasm not
brittle like program code. Common wisdom is vaguely in right direction, but
not exactly: don't need to be soft and squishy, do need to be concise.

Also need, surprisingly, to enforce good software engineering discipline on
evolutionary process! In one run I used byte code as representation, with
CALL and RET instructions. Easiest way to use RET was as indirect branch, so
evolution did that. Resulting code was incredibly, remarkably obfuscated,
should probably have kept some for entering in one of those obfuscated code
contests, as in 20 instruction program with trace so hairy I gave up trying
to follow it.

But evolution had same result as ultra-lazy human programmer, spaghetti code
no building blocks, progress halted. Evolution has no foresight, need to
encourage/enforce modularity. Provide functions as primitives, not
multipurpose abusable stuff like CALL/RET. No goto!

For code representation think functional programming languages. (Koza
dabbled in this but mostly restricted, not full recursion, no lambda etc.
Want the full works if trying for more complexity than he achieved.)

Alternatively, look at Joy = functional version of Forth, never got around
to trying it but looks promising, concatenative property.

For data structures, want flexibility and encourage modularity, best
workhorse structure is associative array, also consider Lisp-style 'code is
data' lists (strict lists, don't expose the cons cells with set-car like
Lisp did!), either way stick as far as possible to functional programming,
minimize mutable data.

Need to find better ways to evolve, better search heuristics and
modification operators. Level 0 = program to solve problem, level 1 =
heuristic that works on level 0 programs (tested by how well it speeds up
evolution of level 0 programs in long term), level 2 = heuristic that
operates on level 1, etc, generalize, have programs that could be described
as level omega (operate on all programs at all levels) etc. Higher levels
require rapidly more processing time to evaluate, but have all levels
running simultaneously so can generate more sophisticated results as time
passes. (I never got past the first couple of levels, came up with vague
outline ideas how to do the all-levels thing before abandoning the area.)

Pick appropriate problem domain, need something that requires little real
world knowledge, has lots of crunchy bits inside, no easy off the shelf
solutions but is easy to check results.

Playing Go is a good one. Does get you into coevolution, which isn't bad in
itself but need to be careful you don't get into circles: A is beaten by B
is beaten by C is beaten by A. Some of the runs I did were oddly reminiscent
of biochemistry, no actual intelligence at playing time but a pattern would
evolve which would be beaten by another pattern which would give way to
another like evolutionary warfare of poisons/antidote chemistry. Quick and
dirty way to avoid: require each new champion to beat all previous ones.

That's pretty much the gist of it, as far as I recall offhand.

-----
This list is sponsored by AGIRI: http://www.agiri.org/email
To unsubscribe or change your options, please go to:
http://v2.listbox.com/member/?list_id=303

Reply via email to