Sampling multiple spikes in large DT regime?

[MasahiroNakano]

Hi!

The current implementation samples binary spikes, but binary spikes only follow a Poisson process when λ⋅Δt ≪ 1.
When using a relatively large time step — for example, 5 Hz (Δt = 200 ms) with a maximum firing rate of 20 Hz — binary spikes break down.

One workaround is to bin more finely; using 50 Hz or 100 Hz will likely avoid the issue.
However, another approach might be to allow multiple spikes to be sampled within a single frame, which could solve the problem without being too tedious.

I might be missing something, or perhaps this has already been considered and intentionally avoided — hence I'm posting this in Discussions instead of Issues.
Happy to hear any thoughts or feedback!

@TomGeorge1234

[TomGeorge1234]

I agree this would be, overall, a better set-up, and I really like the idea of using it to get past having to use small time bins which unnecessarily slows things down. I think I realised the current approach -- binary spikes -- was a mistake and have since moved to integer spikes for more recent projects e.g. KalMax.

The only problem I foresee is that this might temporarily break things like plotting utils, or users downstream pipelines which explicitly or implicitly suppose binary spike arrays.

Since the core change is trivial (these three lines) want to give it a go? Try it on a local fork and see which demos or utils break? If relatively few we could add it to the next major version.

A second, less universal option, is to write a utility which samples spikes from the firing rates. Instead of Neurons.history['spikes'] just call utils.sample_integer_spikes(Neurons.history['firingrate'). This is a bit of a botch job though (I've used it myself) and might just confuse people. We should probably come down one side of the fence or the other.