Add function to inhibit complete networks

[jgosmann]

This was proposed in nengo/nengo#1288 and after extensive discussion in nengo/nengo#1301 it was decided to implement such a function in nengo_spa.

Additional discussion is required to decide wether to go with the approach in nengo/nengo#1288 or write a function that creates a node that can be connected to.

[jgosmann]

@tcstewar @tbekolay @xchoo
We still have to decide which variant to implement. The two options that came up:

1. Directly create the connections as done in Add function to inhibit complete networks. nengo#1288. The advantage is that a list of all created connections can be returned for easy manipulation.
2. Create a node that can be connected to (@xchoo's solution). Unlike @xchoo's code, I would assume the function to return the node because modifying the network might mess with other user-defined attributes. The node solution allows to connect multiple signals to the inhibitory node. Though, it still requires to create a nengo.Connection for each signal. So I'm not sure if that's much better than 1. where each of these connections could be created by one functions call to inhibit_net. Also, it is not clear how to access the connections after creation to change them.

Any other arguments for one or the other approach?

[jgosmann]

From teaching standpoint it seems to me really helpful to have this function. It is so much easier to explain how to inhibit a SPA State with inhibit_net(from, to) than explaining that weird loop over the ensembles that is otherwise required.

[tbekolay]

Personally I prefer 2 because it results in fewer connections if you have multiple things that can inhibit the ensemble. E.g., if there are 8 ensembles in the network, having two sources of inhibition results in 16 connections with option 1 and 10 connections in option 2. A single connection to a node also feels easier to manipulate (to me) compared to a list of connections.

Regarding the connections that are created within the function, it doesn't feel to me like you would ever need to modify those connections unless you wanted to inhibit some ensembles more than others? Otherwise, anything you would want to do to each connection you should instead do to the connection to the node that is returned by the function.

While I think that returning the node is a better solution for a helper function, there is precedent for adding attributes to an object through a method in EnsembleArray.add_output. Not saying that's an ideal solution, but we've been using it for a long time so it must not be too bad.

[jgosmann]

Regarding the connections that are created within the function, it doesn't feel to me like you would ever need to modify those connections unless you wanted to inhibit some ensembles more than others?

Maybe if someone wants to do learning on the inhibitory connection? In that case the learning rule needs to be set on each connection and it might not be possible to do that in a connection to a node.

But I suppose it would also be valid to say that in this case someone has to create those connections manually.

[xchoo]

I'll also point out that having a node that all of the inhibitory signals connect to make it easier to debug the network if you have multiple inhibitory signals going to one network (as Spaun does... everywhere)

With 1, you'd have to probe all of the connections going to the network, since activity on one of these connections will inhibit the network.

With 2, you'll just have to probe the output of the node to see when the network is being inhibited.