Subject: Re: adb & genetic algorithms
To: None <port-mac68k@NetBSD.ORG>
From: Rick Hawkins <rhawkins@iastate.edu>
List: port-mac68k
Date: 05/07/1997 10:46:59
> This is an interesting idea for reverse engineering, but unfortunately
> the search space is infinitely large in concept: i.e. you may have to
> write or read any bit any times at any order. When hardware I/O space
> is N bit in size, you can't even assume the search space is 2 * N!
> because you may have to repeatedly read or write one bit many times.
> IOW, even though we are interfacing the ADB chip with a small number
> of bits, the state machine behind the bits may be any one of
> infinitely many of such machines.
That would definitely prevent this from working. For a GA to work, we
need to be able to explicitly parameterize the problem.
To my knowledge, noone has gotten even as far as poor results using a GA
for a neural net (or any other AI work. AI & AL are both computation
heavy, giving a geometric progblem).
Also, they are poor at evolving programs in general. For real machines,
the problem is that almost all of the possible programs are null, and do
nothing (at least nothing useful). And if this were dealt with
(possible, but a lot of work easier solved in other ways), there's a
serious ethical/moral problem: a success would likely be a virus with a
strong ability to adapt & protect itself. And should it escape . . .
which isn't as preposterous as it sounds, as it would likely have
produced some kind of functional model of the machine while competeing
for resources . . . but anyway, i'm babbling (really don't want to study
for tomorrow's final).
More to the point, and possibly useful, is that there *has* been success
by a couple of folks (one of whom I work with) at creating artificial
languages to evolve. These have a small number of instructions. [At
this point, many of you will start having a better Idea of what I'm
talking about than I do :) ].
These programs are set up as trees. Breeding is done not by swappng
bits/parameters, but by grafting a branch from one tree to another.
Generally, programs are limited to a certain number of steps (to prevent
an infinite recursion). Programs may also be allowed "functions" which
could be called from any point in the tree.
If I'm understanding what you're saying about the initialization, there
are only a very small (2^4?) number of possible operations, but the
order of these operations is unknown. If we have some reasonable idea
about the number of such operations, this might be representable in a
tree.
just off the cuff, the possible instructions could be the 8 3 bit
operations, each of which take a 1 bit operation, store (to a memory),
recall (from a memory), and math or logical operations (to manipulate
prior action's stored values).
rick