Arbitrary spike kernels

[thesamovar]

People often ask for the ability to define arbitrary spike kernels (rather than using differential equations). We've resisted this in the past because it's much less computationally efficient than using DEs, but maybe it's worth considering? We'd just need to maintain a recently received spikes queue much like the future spikes queue (possibly even using the same data structure), a table of values, and then sum over those. Worth it or not?

[mstimberg]

I'd tentatively say that this would be a good idea, but it obviously still requires quite a bit of discussion about the syntax. There are also two possible approaches, one would be that the user specifies an equation (not making any real syntax proposal here):

syn = Synapses(..., pre_trigger='g_post += alpha**2*(t-t_spike)*exp(-alpha*(t-t_spike)')

and the other on to rather reuse TimedArray and link it to an event.

The first option would of course be neither in many ways but has the disadvantage that there is no clear way how to decide how far back in the time we have to store spikes. So this would have to be defined in a separate argument or with some special syntax. Or maybe it could be something in the equations:

g_post += alpha**2*(t-t_spike)*exp(-alpha*(t-t_spike) : siemens (triggered by: pre, duration: 100*ms)

The advantage of reusing TimedArray would be that we know its length and could therefore determine how far we have to look back. Obviously the disadvantage would be to move model details out of the model description and into Python code.

So to some up, I agree that something like this could be useful and I also agree that technically it would probably not be extremely challenging. It'll need plenty of discussion about syntax and other details, though.

[thesamovar]

I would allow for both equations and TimedArray I think. We can discuss the syntax if and when someone feels like implementing it I think. Definitely needs some discussion but shouldn't be too complicated I'd say.

[Snow-Crash]

Just some general discussion. Directly simulating with kernel like alpha**2*(t-t_spike)exp(-alpha(t-t_spike) seems very inefficient. At every dt, simulator has to go over the entire history to calculate the output. Generally, using signal processing tricks, e.g. z-transform/laplace transform, it should be possible to approximate or even equavalently express arbitrary kernel by difference equation. Under the hood, brian2 is clock driven, supporing difference equation seems much easier.

[thesamovar]

That's what we currently recommend people to do (https://brian2.readthedocs.io/en/stable/user/converting_from_integrated_form.html).