tcstewar

I think I'm not quite sure what the difference is between Option 2 and Option 3, so I'm going to try writing out example code for all the options, to...

If I've got the above options right, then in terms of syntax I really like Option 3. It's consistent with the general idea of Connections, and I like that it...

> we should really allow separate rates for each rule. So for example with Option 3, we'd need a node for each rule (i.e. it should be an attribute on...

Has anyone looked at optimizing the E->I connection (rather than just setting it as a uniform constant connection weights)? It feels like you could do something like backprop there.....

This would also be something good to think about when figuring out what sort of build-process hooks we want: #869

I really should get around to doing this. I was just reminded up it by Chris posting this paper, which does some nice analysis of what happens with pure inhibitory...

Here's a quick implementation of the standard Parisien transform in Nengo 2.0 ``` python def parisien_transform(conn, model, inh_synapse, inh_proportion=0.25): # only works for ens->ens connections assert isinstance(conn.pre_obj, nengo.Ensemble) assert isinstance(conn.post_obj,...

I think this may be slightly more recent: https://github.com/tcstewar/nengo_parisien/blob/master/Parisien%20v2.ipynb I also just committed a change I made ages ago to fix the incorrect synapses in that example......

Awesome! That's a nice way to do it.... If we want a few more benchmark tasks, we can use the `nengo_benchmarks` https://github.com/tcstewar/nengo_benchmarks/ if we also pass them through `https://github.com/tcstewar/nengo_normal_form` (which...

> Haven't read the rest of the issue yet (but looking forward to it!), but this seems like the Nengo Enhancement Proposal (NEP) repository might be a better place for...