Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SpikeSourcePoisson not random? #621

Closed
andrewgait opened this issue Jan 17, 2019 · 2 comments
Closed

SpikeSourcePoisson not random? #621

andrewgait opened this issue Jan 17, 2019 · 2 comments

Comments

@andrewgait
Copy link

This was pointed out to me by a NEST / SpiNNaker user; they were running simple synfire chains along with a SpikeSourcePoisson using NEST and SpiNNaker, and each time they ran using NEST (which in their particular case, means they are using the default in PyNN) they get the same answer, whereas they should be getting different answers (which they do on SpiNNaker because our implementation passes in a different random seed each time when building the number sequence). It seems to me from looking at RandomSpikeSource:

https://github.com/NeuralEnsemble/PyNN/blob/master/pyNN/neuron/cells.py#L518

that the seed will be the same each time a script that runs on the same number of MPI processors is run, as state.native_rng_baseseed appears to be set to zero each time, but I might be missing something... ? Is there something this user should be doing in NEST instead, or is this an oversight in PyNN?

@apdavison
Copy link
Member

This is a deliberate choice in PyNN. Running the same script twice should always give the same results unless the user has made a deliberate choice for it to behave otherwise (by explicitly changing the seed), e.g.

import random
setup(grng_seed=random.randint(0, 1000000))

Ideally, the behaviour of sPyNNaker should be changed to match, although I realise this might have an impact on existing scripts.

@apdavison
Copy link
Member

Added more information to the documentation.

pgleeson added a commit to pgleeson/PyNN that referenced this issue Mar 19, 2019
* master:
  Add more information about random numbers (cf NeuralEnsemble#621)
  Update installation docs to reflect support for NEST 2.16.0
  FromListConnector now accepts empty lists, as it is supposed to.
  ...aaand forgot to add this too.
  Release 0.9.3
  Documentation update
  Forgot to add this to Git when doing the last release
  Fixed outdated documentation
  Don't use `close_fds=True`
  More robust test (changed connection ordering in NEST 2.16.0 should not break test)
  Workaround for what seems to be a regression in NEST 2.16.0
  Partially fixed a bug revealed by the stricter range checking of Neo 0.7.
  It appears that in NEST 2.16.0, "threads" must be set before "spike_precision"
  Trying to fix problem caused by nest/nest-simulator#716
  Updating NEST extension models to work with NEST 2.16
  Testing with NEST 2.16
  Added quorum requirement.
  Added document on project governance
  Added example of using IntFire1 model
  Added support for NEURON "ARTIFICIAL_CELL"-type neuron models.
pgleeson added a commit that referenced this issue Apr 25, 2019
* sonata: (41 commits)
  Note to self: run the unit tests before making a commit!!
  In sonata module, fully implement filtering in node sets based on node population attributes; support step current injection
  Allow slicing an Assembly with a boolean mask
  missed version number in docs
  Release 0.9.4
  Added some documentation for the SONATA support
  Add more information about random numbers (cf #621)
  sonata module: Support for "target_simulator = 'NEST'" and for recording state variables.
  Update installation docs to reflect support for NEST 2.16.0
  FromListConnector now accepts empty lists, as it is supposed to.
  WIP: testing Sonata import (#612)
  ...aaand forgot to add this too.
  Release 0.9.3
  Documentation update
  Forgot to add this to Git when doing the last release
  Fixed outdated documentation
  Don't use `close_fds=True`
  More robust test (changed connection ordering in NEST 2.16.0 should not break test)
  Workaround for what seems to be a regression in NEST 2.16.0
  Partially fixed a bug revealed by the stricter range checking of Neo 0.7.
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants