nengo / nengo

A Python library for creating and simulating large-scale brain models
https://www.nengo.ai/nengo
Other
822 stars 175 forks source link

Warning when using function parameter for nengo Connections #485

Closed xchoo closed 10 years ago

xchoo commented 10 years ago

Building a connection from a Node to an ensemble should throw a warning (about not being biologically plausible or something..)

tcstewar commented 10 years ago

I think this is the same as issue #428 where the consensus was to disallow this completely, rather than throw a warning.

xchoo commented 10 years ago

Well, I don't think we should disallow function outputs on Nodes altogether (if you connect a node to a node, I'm fine with that).

tcstewar commented 10 years ago

Hmm.. I guess for me if you really want a function on a Node output, you could just as easily do that function inside the Node itself.

My main worry with a warning is that I'm not sure it's strong enough of a deterrent. But I can definitely see starting with just putting a warning in place, and maybe in the future disallowing it. Or, perhaps starting with disallowing it and if we hit a use case where it really makes sense to allow it then we switch it to a warning.

tcstewar commented 10 years ago

Ah, never mind, I see an important distinction between this issue and #428 . For issue #428 it was to disallow functions coming out of "passthrough" Nodes in particular (i.e. Nodes with no function that just pass their input to their output). That I definitely think we want to disallow.

Does that cover the cases you're thinking of with this? Do you have a particular example of a non-passthrough Node that you'd want a warning when you compute a function out of it?

hunse commented 10 years ago

I definitely think we should disallow functions on passthrough nodes (as described in #428).

As for the general case described here, I'm not quite sure what the problem is. It would seem to me the fact that they're using nodes should make it clear to the user that this is not biologically plausible, and I could see this being useful if you want a wide variety of inputs that are all functions of one input; for example, you could easily input sin(t) and sin(t)**2 to two different ensembles while only creating one 1D input node.

xchoo commented 10 years ago

Hmm. I guess right now I'm just dealing with passthrough nodes. The reason for this issue is with the Spaun code I'm working on, there are a lot of networks and subnetworks. I could just as easily connect a node (with or without a function output) to an ensemble, apply a function to the connection, and be none the wiser.

tcstewar commented 10 years ago

Hmm. I guess right now I'm just dealing with passthrough nodes. The reason for this issue is with the Spaun code I'm working on, there are a lot of networks and subnetworks. I could just as easily connect a node (with or without a function output) to an ensemble, apply a function to the connection, and be none the wiser.

That accidental error is exactly what #428 is meant to cover, and I'd definitely want to keep that as an error, not as a warning.

drasmuss commented 10 years ago

Implemented in #502