Loading ...
Sorry, an error occurred while loading the content.

6231RE: Starting with Neat, the XOR problem, some questions

Expand Messages
  • kenstanley01
    Jan 5, 2014
    • 0 Attachment
      Hi Simon, I think you've made the right decision in starting with NEAT before moving to HyperNEAT (although you do not state it explicitly, your experiment with the checker boards is really a HyperNEAT experiment).  Because HyperNEAT is built on top of NEAT, it will not work if the NEAT implementation below it is faulty.  Generally building a reliable NEAT requires a fair amount of validation and testing to make sure it works.  XOR is a good way to do that.  So let me try to address your questions:

      First, indeed nodes do receive new innovation numbers and should be treated just like connections in this respect.  However, your question on node numbering actually also relates to connection numbering - you could ask if e.g. a connection between the same two nodes should receive the same or a different number.  This issue has been discussed extensively in the past (sometimes on this group) and there are various opinions.  For some basic insight, please see the question "Should a record of innovations be kept around forever, or only for the current generation? " at http://www.cs.ucf.edu/~kstanley/neat.html , where there is a FAQ for NEAT.

      Note that we cannot assume everyone in the initial generation is the same species.  While that is often true, the compatibility distance function, which determines the distance between two genomes, also includes the notion of average weight difference.  Because weights do differ in the initial population, depending on the compatibility threshold, it is possible that NEAT could speciate even the first generation into more than one species.

      From your question on speciation, I didn't notice you mentioning the fitness sharing step, which is important though it can be implemented in different ways.  But in NEAT in general offspring are first assigned on a per-species basis proportionately to the average fitness of each species.  I am not sure if you are remembering to take that step (i.e. fitness sharing), but it is critical to the protection of innovation so if you are uncertain what it means we should discuss it further.  Selection, i.e. who gets to reproduce, is then performed within each species.

      Beyond that, the particulars of the exact probabilities of various operations varies a lot by implementation, and there are a lot of different NEAT variant implementations, so I wouldn't get hung up on the very specific numbers in our original paper.  However, I do recommend my C++ version of NEAT at http://nn.cs.utexas.edu/?neat-c as a good reference for a reproduction procedure, though other implementations like SharpNEAT are likely equally helpful. 

      The fact that you get 150 species in a population of 150 is definitely pathological and means the system is not working well.  Note that adding a connection or node should not guarantee that a new species is created.  Rather, the compatibility distance function will take that addition into account, and the compatibility threshold will decide *if* it is enough to warrant a different species.  If the threshold is high enough, it will see it as the same species.  However, what people usually do with NEAT implementations in recent years (maybe going back even to that paper) is make what is called a "dynamic compatibility threshold" that automatically adjusts itself to try to target a specific desired number of species.  So say you have a species target of 10.  Then you can say, if I see more than 10 species, I will make the dynamic threshold go up to make membership more inclusive.  If I see less, the threshold goes down to make membership more strict.  Then the system can maintain an equilibrium number of species, avoiding the kind of explosion you are witnessing (which kills evolution because a species of size 1 has no diversity from which to select).

      Overall it sounds like you're still getting familiar with NEAT.  I would advise looking at some implementations to help with this process.  It is not trivial to implement and there are certainly design decisions that different implementations approach differently, but they all follow the same general framework.  It's understanding that general framework that is important.  Also, to add on to Jason's response, there are a number of HyperNEAT implementations that you can check out as well later once you're ready in the future for HyperNEAT.  See the Software section at http://eplex.cs.ucf.edu/hyperNEATpage/HyperNEAT.html for those.

      Best,

      ken
    • Show all 7 messages in this topic