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

Re: Questions about NEAT mutation implementations

Expand Messages
  • Kenneth Stanley
    Wesley, the reason that links coming out of the bias are not splittable originates with what I understood to be a canonical conceptualization of bias, which
    Message 1 of 6 , Mar 1, 2007
    • 0 Attachment
      Wesley, the reason that links coming out of the bias are not
      splittable originates with what I understood to be a canonical
      conceptualization of "bias," which is that bias is a property of each
      node in the network. In other words, in a general ANN
      conceptualization, you can think of each neuron as having a bias
      "field" within its representation.

      However, in contrast, in NEAT I was originally trying to keep
      parameters out of the nodes so that all parameter mutations could
      occur within links. Making the bias node an input made this possible:
      Now the "bias" of any particular node could be controlled by a *link*
      from the bias node to the node to be biased. However, conceptually,
      that link is not like other links because it is best conceived as an
      internal property of the node being biased.

      The conclusion is that you should not be able to split an internal
      paramter of a node, since it is not "really" a link.

      Of course, in practice, it probably wouldn't hurt performance to
      remove that restriction, but you can see it was originally motivated
      by a fairly subtle technical consideration.

      ken

      --- In neat@yahoogroups.com, "tansey4" <tansey4@...> wrote:
      >
      > Thanks for the response Ken. I realize you haven't worked on the code
      > in a long time, so I'll try to keep my questions as conceptual as
      > possible.
      >
      > To that end, I have one more question. The mutate_add_node method
      > tries to find an eligible link to insert a new node into. To
      > determine eligibility, it looks at 2 criteria:
      > 1. Is the link enabled
      > 2. Is the input node of the link a bias node
      >
      > Why does criteria #2 exclude the link from having a node inserted
      into it?
      >
      > Thanks,
      > Wesley
      >
      > --- In neat@yahoogroups.com, "Kenneth Stanley" <kstanley@> wrote:
      > >
      > > Hmm let me try to recall the reasoning I had several years ago when
      > > I wrote that function :)
      > >
      > > First, I should note that I rarely ever use mutate_toggle_enable
      > > (its probability is usually set to zero in my runs). I have found
      > > it to be mainly just disruptive. However, others here have
      > > developed more principled ways of pruning networks which probably
      > > work better than my random toggler.
      > >
      > > In any case, I believe that you are correct- if you really want to
      > > keep everything together in the network then it would be necessary
      > > to check both the in-node and out-node.
      > >
      > > ken
      > >
      > > --- In neat@yahoogroups.com, "tansey4" <tansey4@> wrote:
      > > >
      > > > Hi all,
      > > >
      > > > I'm working on my own implementation of NEAT using the rtNEAT code
      > > as
      > > > a starting point. I am on the mutation operators and had a
      > > question
      > > > about Genome::mutate_toggle_enable(int times). When the method
      > > finds
      > > > a gene to disable (if the gene is enabled), it does a check to see
      > > if
      > > > it can do this without fragmenting the network. The comment says:
      > > >
      > > > > We need to make sure that another gene connects out of the in-
      > > node
      > > > > Because if not a section of network will break off and become
      > > isolated
      > > >
      > > > My question is does it only check the in_nodes and not the
      > > out_nodes?
      > > > If we don't check out_nodes, wouldn't it be possible for the
      > > outputs
      > > > to become disconnected from the network? If you have a network of
      > > 1
      > > > input and 2 output nodes, where the input is connected to both
      > > > outputs, wouldn't this method consider it valid to disable one of
      > > the
      > > > connections?
      > > >
      > >
      >
    • Kenneth Stanley
      Hey Wesley, sorry for the long wait on this question. I think the answer is that if you draw out the diagrams of the two alternative ways of splitting a
      Message 2 of 6 , Mar 11, 2007
      • 0 Attachment
        Hey Wesley, sorry for the long wait on this question.

        I think the answer is that if you draw out the diagrams of the two
        alternative ways of splitting a recurrent link, you will find that
        both of them are consistent, so it could have been done either way.

        But here is a fairly subtle reason for making the first link
        recurrent: If the recurrent connection is coming out of an output,
        then technically if you called the first link feedforward, you would
        be creating a new layer *above* the output layer (because now a link
        leads up from the output to a new node). Technically, the outputs
        should always be the highest layer in the network. Therefore, by
        doing it the way it does in origianl NEAT, it avoids this
        inconsistency.

        It's a good question though and worth some thought. Others may have
        differing views. I'm not sure how other versions of NEAT handle
        this issue.

        ken

        --- In neat@yahoogroups.com, "tansey4" <tansey4@...> wrote:
        >
        > One more follow-up question about mutate_add_node. When the method
        > inserts the new node and creates 2 new connections, why does the
        first
        > link inherit the recurrent flag and not the second link?
        >
        > The way I see it, you have 2 nodes (A and B), and the chosen link
        > between them is recurrent. You insert a new node (C) inbetween A
        and
        > B, so now instead of the link being B->A, it's B->C->A. It seems
        like
        > you should label the C->A link as recurrent. Or does this not even
        > matter?
        >
        > Thanks,
        > Wesley
        >
        > --- In neat@yahoogroups.com, "tansey4" <tansey4@> wrote:
        > >
        > > Thanks for the response Ken. I realize you haven't worked on
        the code
        > > in a long time, so I'll try to keep my questions as conceptual as
        > > possible.
        > >
        > > To that end, I have one more question. The mutate_add_node
        method
        > > tries to find an eligible link to insert a new node into. To
        > > determine eligibility, it looks at 2 criteria:
        > > 1. Is the link enabled
        > > 2. Is the input node of the link a bias node
        > >
        > > Why does criteria #2 exclude the link from having a node inserted
        > into it?
        > >
        > > Thanks,
        > > Wesley
        > >
        > > --- In neat@yahoogroups.com, "Kenneth Stanley" <kstanley@> wrote:
        > > >
        > > > Hmm let me try to recall the reasoning I had several years ago
        when
        > > > I wrote that function :)
        > > >
        > > > First, I should note that I rarely ever use
        mutate_toggle_enable
        > > > (its probability is usually set to zero in my runs). I have
        found
        > > > it to be mainly just disruptive. However, others here have
        > > > developed more principled ways of pruning networks which
        probably
        > > > work better than my random toggler.
        > > >
        > > > In any case, I believe that you are correct- if you really
        want to
        > > > keep everything together in the network then it would be
        necessary
        > > > to check both the in-node and out-node.
        > > >
        > > > ken
        > > >
        > > > --- In neat@yahoogroups.com, "tansey4" <tansey4@> wrote:
        > > > >
        > > > > Hi all,
        > > > >
        > > > > I'm working on my own implementation of NEAT using the
        rtNEAT code
        > > > as
        > > > > a starting point. I am on the mutation operators and had a
        > > > question
        > > > > about Genome::mutate_toggle_enable(int times). When the
        method
        > > > finds
        > > > > a gene to disable (if the gene is enabled), it does a check
        to see
        > > > if
        > > > > it can do this without fragmenting the network. The comment
        says:
        > > > >
        > > > > > We need to make sure that another gene connects out of the
        in-
        > > > node
        > > > > > Because if not a section of network will break off and
        become
        > > > isolated
        > > > >
        > > > > My question is does it only check the in_nodes and not the
        > > > out_nodes?
        > > > > If we don't check out_nodes, wouldn't it be possible for
        the
        > > > outputs
        > > > > to become disconnected from the network? If you have a
        network of
        > > > 1
        > > > > input and 2 output nodes, where the input is connected to
        both
        > > > > outputs, wouldn't this method consider it valid to disable
        one of
        > > > the
        > > > > connections?
        > > > >
        > > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.