Flatten neuron

[jaberg]

Flatten the neuron subdir into the base code dir.

Also, introduce a new high-level Op for implementing LIFNeurons. Like the high-level connection ops, the goal is to make it easier to recognize when populations can be merged by Theano optimizations.

Also, added an "upsample" parameter to the Theano Op which implements running the neuron dynamics at a higher sampling frequency.

[studywolf]

actually that may have been a bit hasty, how do I reopen?

What's the difference between LIF_Op and LIFNeurons? And should there be an LIFRate_Op? Also can we rename the methods not to be make_node and perform? Node means something else throughout the rest of the code. Maybe make_neurons and update?

[jaberg]

Probably fixing it is easier than un-merging, which is not easy.

On Wed, May 1, 2013 at 5:08 PM, studywolf notifications@github.com wrote:

actually that may have been a bit hasty, how do I reopen?

What's the difference between LIF_Op and LIFNeurons? And should there be an LIFRate_Op? Also can we rename the methods not to be make_node and perform? Node means something else throughout the rest of the code. Maybe make_neurons and update?

— Reply to this email directly or view it on GitHubhttps://github.com/ctn-waterloo/nengo_theano/pull/39#issuecomment-17306582 .

[jaberg]

On Wed, May 1, 2013 at 5:08 PM, studywolf notifications@github.com wrote:

actually that may have been a bit hasty, how do I reopen?

What's the difference between LIF_Op and LIFNeurons? And should there be an LIFRate_Op?

LIFNeurons is the same class that it used to be.

LIF_Op is an encapsulation of LIFNeurons' update logic into a single Theano Op, rather than a subgraph (as it used to be).

It probably makes sense to do similarly for LIFRateNeurons (make an LIFRate_Op) but it doesn't have to be done right away.

[jaberg]

On Wed, May 1, 2013 at 5:08 PM, studywolf notifications@github.com wrote:

Also can we rename the methods not to be make_node and perform? Node means something else throughout the rest of the code. Maybe make_neurons and update?

No, these methods have to be named like this, so that Theano recognizes them. The Op interface requires it.

[jaberg]

So does anything really need fixing?

On Wed, May 1, 2013 at 5:27 PM, James Bergstra james.bergstra@gmail.comwrote:

Probably fixing it is easier than un-merging, which is not easy.

On Wed, May 1, 2013 at 5:08 PM, studywolf notifications@github.comwrote:

actually that may have been a bit hasty, how do I reopen?

What's the difference between LIF_Op and LIFNeurons? And should there be an LIFRate_Op? Also can we rename the methods not to be make_node and perform? Node means something else throughout the rest of the code. Maybe make_neurons and update?

— Reply to this email directly or view it on GitHubhttps://github.com/ctn-waterloo/nengo_theano/pull/39#issuecomment-17306582 .

[studywolf]

Ah I see! And nope, that addresses errythan. Huzzah!

[jaberg]

This change will make more sense once there is another LIF_Op implementation using OpenCL.

I've already implemented it (for the timing tests) but there aren't enough other high level model components (and OpenCL implementations of other model components) to see the whole multiple-backend thing in action.

On Wed, May 1, 2013 at 5:33 PM, studywolf notifications@github.com wrote:

Ah I see! And nope, that addresses errythan. Huzzah!

— Reply to this email directly or view it on GitHubhttps://github.com/ctn-waterloo/nengo_theano/pull/39#issuecomment-17307951 .