make drive event times independent of gid (randomisation)

[cjayb]

The drives-API discussed and implemented in #221 retains the old behaviour of assigning a separate seed for each drive. This is an anti-pattern that inherits from a legacy implementation of exogenous input drives (randomisation was implemented at a stage where MPI may already have split the network onto different ranks). In practice, the spike train of each "artificial" input cell is created using a new seed that's based on the cell's GID (plus a fixed offset).

Now that the spike train event times are created in Network, there is no need to keep maintaining the old gid-based seed assignment. However, as current tests are based on legacy output, there will be a need to create a new test suite.

This issue should discuss what is considered "consistent" in terms of event times. For example, the legacy gid-based seeding means that the order in which drives are added influences the spike trains. The same will apply if we simply go with one global prng seed. If we wish to be able to create reproducible spike trains irrespective of the order in which the drives are added, each drive will need a seed.

[jasmainak]

I think this is a great issue to prioritize in the next release.

[jasmainak]

let's move to 0.3 :)

[jasmainak]

close @ntolley @rythorpe ? I am guessing this will be sufficiently addressed after #619 ? The test data set needs to be updated but we need to track it in only one issue ...

[rythorpe]

Isn't this issue more about consolidating the seed values set by the user in a few different places throughout the API into a single seed value?

[rythorpe]

I guess this will be really easy to resolve once we can completely get rid of legacy mode, since we'll then be able to set the seed once and only once (e.g., simulated_dipole(..., seed=0)) which under the hood calls np.random.default_rng(seed=0). Is that kinda what you were thinking @jasmainak?

[jasmainak]

umm ... I don't think you want a single seed. Global seeds have the nasty feature that the randomness depends on the order of operations. Random states are the way to go. See:

https://builtin.com/data-science/numpy-random-seed

But maybe you want to pass around the seed downstream? That may create unintended correlations between your drives though, so I'd be careful of that too

[rythorpe]

Ahh good point. Then we could just pass around a single Generator instance (i.e., that has been seeded in simulate_dipole()) so that we still address the original concern brought up in this issue?

[rythorpe]

Closing due to redundancy with #244. Feel free to re-open if there's is something unique here that should be addressed separately.