mstimberg
commented
10 years ago In the spikegeneratorgroup branch there's a simple version of SpikeGeneratorGroup, limited to an explicit array of indices and an array of spiketimes. It uses a very simple and not very efficient mechanism for getting the spikes, based on a binary search in the sorted times array. It wouldn't be a big problem to implement this more efficiently by e.g. storing the index of the last used spike and continuing from there. And of course there's also the pre-calculated offset method from Brian 1. But I think this kind of optimization can be easily implemented later, as it does not affect the user interface at all.
There are all kind of potential issues surrounding changes of t and dt, although the current simple implementation avoids most by not having any internal state. Either way, I think we should deal with this issue after implementing what we discussed in #183.
Final question: the current SpikeGeneratorGroup only supports one syntax (index array, spike time array) -- do we want to support all the other Brian1 syntax variants as well (list of pairs, etc.)? For a first version we can do without, I think.
Note that the branch is built on top of the linked_variables branch, I'll wait with the pull request until #264 is merged.
thesamovar
Let's have a simple version of
SpikeGeneratorGroupfirst, i.e. one that is based on explicit spike times without any string expressions. Deciding how a more general version with string expressions should look like (and whether we need it at all) happens in #162.