You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The feedforward layout algorithm can get confused some times, and end up giving you backwards connections that could just be forwards connections. E.g., in a network like this:
withnengo.Network(label="test") asmodel:
input1=nengo.Node([0], label="input1")
input2=nengo.Node([0], label="input2")
a=nengo.Node(size_in=1, label="a")
b=nengo.Node(size_in=1, label="b")
c=nengo.Node(size_in=1, label="c")
nengo.Connection(input1, a)
nengo.Connection(a, b)
nengo.Connection(b, c)
nengo.Connection(input2, c)
When you do the feedforward layout, you get
input1 --> a -->
b
input2 --> c <--
Whereas I think what we would usually want is
input1 --> a --> b -->
c
input2 -->
Basically the problem is that all the nodes without input get placed at the same level, and then downstream nodes are incrementally placed further to the right. This means that the "forward" projection from b --> c gets dragged into a "backwards" projection by the location of input2. It looks kind of trivial in this example, but when you're building large networks with multiple inputs at different points throughout the network, it can result in some pretty screwy layouts.
I think to resolve this kind of problem completely you would have to do multiple passes through the network graph (unless someone has a clever idea I'm not coming up with). We're not doing the computation that often though, so that wouldn't be so bad. A simpler solution would be to start by placing all the output nodes, and then work backwards from that. That is of course susceptible to the opposite problem, but I think it is a lot more common for us to have multiple inputs at different points than multiple outputs.
It's not a critical issue, as you can always just rearrange things yourself. It'd just be nice to resolve at some point, so I'm documenting it while I think of it.
The text was updated successfully, but these errors were encountered:
Makes a step towards addressing #109, though still not optimal. At the
beginning of the feedforward algorithm, finds both a starting layer and
an ending layer (the old behaviour was to just find a starting layer).
Then it works forward from the starting layers, as before.
The feedforward layout algorithm can get confused some times, and end up giving you backwards connections that could just be forwards connections. E.g., in a network like this:
When you do the feedforward layout, you get
Whereas I think what we would usually want is
Basically the problem is that all the nodes without input get placed at the same level, and then downstream nodes are incrementally placed further to the right. This means that the "forward" projection from
b --> c
gets dragged into a "backwards" projection by the location ofinput2
. It looks kind of trivial in this example, but when you're building large networks with multiple inputs at different points throughout the network, it can result in some pretty screwy layouts.I think to resolve this kind of problem completely you would have to do multiple passes through the network graph (unless someone has a clever idea I'm not coming up with). We're not doing the computation that often though, so that wouldn't be so bad. A simpler solution would be to start by placing all the output nodes, and then work backwards from that. That is of course susceptible to the opposite problem, but I think it is a lot more common for us to have multiple inputs at different points than multiple outputs.
It's not a critical issue, as you can always just rearrange things yourself. It'd just be nice to resolve at some point, so I'm documenting it while I think of it.
The text was updated successfully, but these errors were encountered: