Navigation

There are four considerations for random number generation and consumption in
PyNN:

Reproducibility:

When comparing simulations with different backends, we may wish to
ensure that all backends use the same sequence of random numbers so that
the only differences between simulations arise from the numerics of the
simulators.

Performance:

All simulators have their own built-in facilities for random number
generation, and it may be faster to use these than to use random numbers
generated by PyNN.

Distributed simulations:

When distributing simulations across multiple processors using MPI, we
may wish to ensure that the sequence of random numbers is independent of
the number of computation nodes.

Quality:

Different models have different requirements for the quality of the
(pseudo-)random number generator used. For models that are not strongly
dependent on this, we may wish to use a generator that is faster but has
lower-quality. For models that are highly sensitive, a slower but
higher-quality generator may be desired.

Because of these considerations, PyNN aims to provide a great deal of
flexibility in specifying random number generation for those who need it, while
hiding the details entirely for those who do not.

All functions and methods in the PyNN API that can make use of random numbers
have an optional rng argument, which should be an instance of a subclass of
pyNN.random.AbstractRNG.
PyNN provides three such sub-classes:

If you wish to use your own random number generator, it is reasonably
straightforward to do so: see Random numbers in the API reference.

Note

If the rng argument is not supplied (or is None), then the method
or function creates a new NumpyRNG for its own use.

All RNG classes accept a seed argument, and a parallel_safe
argument. The latter is True by default, and ensures that the simulation
results will not depend on the number of MPI nodes in a distributed
simulation. This independence can be computationally costly, however, so it is
possible to set parallel_safe=False, accepting that the results will be
dependent on the number of nodes, in order to get better performace.

Note

parallel_safe may or may not have any effect when using
a NativeRNG, depending on the simulator.

In versions of PyNN prior to 0.8, distribution names and parameterisations were
not standardized: e.g. GSLRNG needed ‘gaussian’ rather than ‘normal’.
As of PyNN 0.8, the following standardized names are used: