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