Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feedforward layout improvements #109

Open
drasmuss opened this issue Jun 9, 2014 · 0 comments
Open

feedforward layout improvements #109

drasmuss opened this issue Jun 9, 2014 · 0 comments

Comments

@drasmuss
Copy link

drasmuss commented Jun 9, 2014

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:

with nengo.Network(label="test") as model:

    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.

e2crawfo added a commit that referenced this issue Jun 12, 2014
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant