Optimise out "equivalent" connections from Ensembles about nengo_spinnaker HOT 3 CLOSED

I'm sure you've thought of this, but make sure they don't have PES!

On 22 July 2015 at 16:26, Andrew Mundy [email protected] wrote:

There are some cases where there are lots of "equivalent" connections
coming from Ensembles, e.g.:

nengo.Connection(a, b)
nengo.Connection(a, c)

It might be beneficial to combine these together (on SpiNNaker) so that
the same value is sent for each connection, i.e, they will share a decoder
matrix. As this is equivalent to using cached decoders I'm guessing there
is no reason that this can't be done?

@tcstewar https://github.com/tcstewar do you have any thoughts/concerns
regarding this?

—
Reply to this email directly or view it on GitHub
https://github.com/project-rig/nengo_spinnaker/issues/49.

from nengo_spinnaker.

It might be beneficial to combine these together (on SpiNNaker) so that the same value is sent for each connection, i.e, they will share a decoder matrix. As this is equivalent to using cached decoders I'm guessing there is no reason that this can't be done?

Ah, I Actually didn't know that wasn't done already. Yup, we should only compute one decoder there and we should only store it once.

I actually have some code I've been working on to collapse together all the Connections coming out of an Ensemble into one big decoder (inspecting the Connection slices and function and solver to make sure it's allowed). However, it's all happening at the nengo level (as it it creates a passthrough node and sets it up so that the Ensemble only has one output Connection, and that one Connection goes to the new passthrough Node), so it might not be useful here.

from nengo_spinnaker.

This was managed in #66.

from nengo_spinnaker.