Design for a Darwinian Brain Part 1 and Part 2 + Video

Design for a Darwinian Brain Part 1 and 2 by Chrisantha Fernando and Vera Vasas will be online later today on the x archive. We've just submitted to Living Machines 2013 which will be in the Natural History Museum in London. I would consider it a great honour to be able to speak there about this work which unites Darwin, Bayes and Hebb (and Fisher).

http://www.frontiersin.org/Computational_Neuroscience/10.3389/fncom.2012.00024/abstract

The framework was defined above in our broad ranging, sprawling and perspectival (biased but deeply sensible :) ) Frontiers paper which was genuinely "frontiers" kinda stuff I believe. Shortly I'll post links to the papers on the x archive based at Cornell University.

Here are the papers on the permanent archive.

Design for a Darwinian Brain: Part 1. Philosophy and Neuroscience

http://arxiv.org/abs/1303.7200

Design for a Darwinian Brain: Part 2. Cognitive Architecture

http://arxiv.org/abs/1303.7201

BACK TO THE CODE-FACE

OK, so post-arxiv'ing, lets get back to the code-face. One of the issues with the current code mutation operator which mutates homogeneously the sensor input to atom0 and the motor output of atom2 in the 3 atom SHC molecule is that single mutations of atom0 or single mutations of atom2 are unlikely to produce functional molecules because the probability of them BOTH mutating to a s-m pair that has influence on each other is very low, e.g. s mutates to the right ankle and m mutates to the fingers of the r hand. It is unlikely that in this case SHC will be able to reduce the value of the sensors.

One way around this is to allow multiple sensor and motor vectors to be encoded by atom0 and atom2. In this case, mutation should also simultaneously affect the size of the parameters out of the SHC atom (unless by default a large parameter length is output from that atom and just ignored).

The motor actions will then try to minimise the sum of sensor values. OK, so now 10 sensors and motors are encoded. This number can decrease if more than one motor value in the motor vector has the same key. It is the sum of sensor values that the game tries to maximize/minimise. OK this seems to work. Various sets of s-m vector pairs are discovered during the course of a run. Let us examine some of those here. To do so, it is useful to be able to pickle the population of actors and games that have evolved into a file, and to be able to load the system with these previously evolved actor and game molecules at will.

OK, lets put in another video. Here is the behaviour at the beginning of evolution, and after a few generations of evolving the above 3-atom molecule for the maximisation of sum of joint angles game. Pop size = 50. Mutation rate = 10% for sensor and motor vector per position. vector length = 10 (i.e. 10 sensors and 10 motors are evolved). After a few generations there is some improvement in fitness on this game..

Its not really clear form this what exactly are the s-m pairs that are evolved. Further analysis is required of the evolved molecules. Also, there is currently an annoying copying memory problem in the python code that I need to sort out before anything else. Just did it. It was probably the iteritems was returning an unsorted list of actors so that the molecule objects were not uniquely representing a molecule properly, it was sorted to a list and then made into an iterator in the bold line below.


  def recordMolecule(self):
    mol = []
    for k,act in iter(sorted(self.actors.iteritems())):
      if act.active is True:
        mol.append(act.id)
    if mol not in self.molecules:
      self.molecules.append(mol)
      self.moleculeFitness.append([0])
 #   print "Molecules = " + str(self.molecules)

    for index, i in enumerate(self.molecules):
 #     print str(mol) + " compared to " + str(self.molecules[index])
      if str(mol) == str(self.molecules[index]):
 #       print str(mol) + " is the same as "+ str(self.molecules[index])
        return index
   

Discussion 

So in terms of 'dance' the simplest abstraction is to ask the dancer to move to a position, a single position that minimises or maximises some function. If one were to do minimalist conceptual dance from the bottom-up this would be where one starts. This is what our SHC 3-atom molecules does, it seeks the static joint angle parameter vector which minimises the sensory vector sum.

An extension is to permit the parameter output of atom1 (SHC atom) to control e.g. the oscillation rate of joint motors, or some dynamic parameterization of motion itself. This would require a more complex motor interpreter atom than atom2 currently. Atom2 currently takes the parameters of atom1 and simply executes them as motor actions. Instead, a more complex motor atom interpreter would take parameters and use them, e.g. to specify dynamic motor primitives (DMPs). This open-ended space of motor interpreter atoms requires that the motor atom function can be mutated.

Oooo. Today I became aware of this! Powerplay by the Schmidhuberists. Lets see if they've got what we've got :)

http://www.idsia.ch/~juergen/ICDL2012powerplay.pdf
http://arxiv.org/pdf/1210.8385v1.pdf

OK, the next thing to implement is the reacting to resistance molecule described in Part 2. above. OK lets just forget that and choose something simpler. Lets try to get it to crawl!