[FRIAM] enough of Robert Rosen

[Marcus G. Daniels]

Glen E. P. Ropella wrote:
>> In what way does Genetic Programming not provide an efficient cause?  
>> Having a stochastic aspect, and the possibility to define new 
>> instructions, it seems to me to provide an escape from anything a human 
>> might have intended.   This learning algorithm could escape the 
>> constraints of being a `tool' by being used in a robot with similar 
>> senses as ours and interacting with the conditions of the `real' world.
>>     
>
> Well, correct me if I'm wrong, but GP currently requires a human to set
> up the objective function.  And even in the cases where a system is
> created so that the objective function is dynamically (and/or
> implicitly) evolved, my suspicion is that the GP would soon find a
> computational exploit that would result in either an infinite loop
> (and/or deadlock), crash, or some sort of "exception".
>   
The objective function can be to an extent arbitrary and self-defined by 
the agent, but there must be a large implicit emphasis on avoiding 
death.  In a simulated world, a way to deal with exceptions is to trap 
them, and then reflect that in the objective function.  Existing memory 
management hardware, operating systems and programming languages have 
good facilities for trapping exceptions.

Imagine you have some program evolving in a process on a Linux system.  
Yes, a program could [try] to allocate so much memory that system would 
crash, or find a stack exploit (e.g. to get root and compromise the 
kernel), but by in large the way a broken program would die because the 
memory management hardware trapped illegal memory requests.  If a 
process actually succeeds in killing the whole system, it's a security 
bug in the operating system (or secure programming language, etc.).  As 
for infinite loops or deadlocks, these are things that a management 
process can readily detect.   For the worst case, satellites typically 
have independent monitoring hardware that reboots the main operating 
system should it become unresponsive.  But normally could you just have 
one software process monitoring the performance of the others.  And here 
I mean performance in the sense of CPU utilization (e.g. is it cycling 
through the same program counter range over and over) and wall clock 
runtime.  This is all in the context of a simulated environment, of 
course.  In the robot example, the robots would just slump on the ground 
or jump up and down or whatever until its energy supplies were exhausted. 

Marcus