Invalid axon type bug #278
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some import statements just imported `scipy` when we needed `scipy.sparse`. Import order differences made this an occasional bug. Fixes #252.
This allows us to do a proper `bones-check` with `black`. The hardware tests are still in 3.5.2 to support NxSDK. This commit also fixes some slight changes by `nengo-bones` 0.6.0 that were missed in the upgrade commit because of the missing `bones-check`.
Not backwards compatible with previous versions.
This is useful for testing SNIPs.
- Add a timer around the `Simulator._run_steps` call, to measure the time taken for all steps. - Connect to the board outside the timing loop, so that this does not count towards the step time. - Add a timer specific to SNIPs, to get the most accurate timing (after we call the board run function, so all setup has happened).
This reduces unnecessary communication with the chip
The host SNIP runs on the host and facilitates communication with the superhost using sockets. This is faster than using the default RPC interface. We also take care to make sure both the host and chip SNIPs end properly, by sending a message with a negative spike count. This helps to eliminate board hangs. To allow the host SNIP to work with multiple `run` calls, we keep it idling in between `run` calls, waiting for a message. If the board disconnects before a subsequent run call, the negative spike count message will tell the host SNIP to stop.
This improves performance by reducing the number of channel reads.
This allows the Nengo model on the (super)host to be running simultaneously with the chip, reducing time per step but adding in a one step delay between the (super)host model and chip model.
We're typically calling it one step at a time, in which case we can simplify it and make it faster. TODO: - Fix up original collect_receiver_info and remove profiling code - The original can probably do the same thing were we get rid of the receive and collect functions on the nodes, since essentially these just populate and read lists in those nodes. - Only use the single step function if we know we'll be running one step at a time (this might be always right now).
Previously, fixed checking of `neurons_per_dimension` and fixed value for `add_to_container` made `get_ensemble` not particularly useful for users trying to make their own `DecodeNeurons`. Now, these are configurable, and default to the values that users would likely want.
This benchmark has a number of ensembles in parallel on the chip. It can be used to test chip input and output speeds, and learning. TODO: - Uses weird intercepts. Just use normal ones. - Currently only set up for learning. Allow it to be used without learning, and without funnelling on inputs and outputs.
- Remove weird intercept distribution - Allow input and output funnelling and learning to be configured
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is to document a bug we were getting in the
parallel_ensemble.pybenchmark. The first step is probably to copy theparallel_ensemble.pybenchmark from here to master, to see if the bug still happens in master. This branch also has a number of features added in #256, so it might also be worth checking if the error occurs there.