brian-team/brian2 — pull request #352 by mstimberg (2014-10-28 16:41:51+00:00)
Title: Synapse delay fixes

This fixes two quite important bugs for the handling of synaptic delays.

* The C++ spike queue did not support homogeneous delays (when you use `delay=...` as a keyword to `Synapses`) at all, doing more or less undefined things when using it (via the Cython extension or when using standalone)
* Delays where converted into integers using the synaptic clock dt, but interpreted according to the source clock dt

Note that for the first point, we don't yet deal with homogeneous delays in any optimized way, they are simply converted into a vector of identical delays in the `prepare` step (see #169).

The second point did make me realize a major problem, though (discussing everything for the `pre` pathway, but of course it applies to `post` in the same way): it makes sense to run the `pre` pathway on the source clock, since there will never any spikes happening in between two time steps of the source. But this has non-trivial consequences when using delays -- all of these delays will be rounded to multiples of the source's time step. Code like this will go very wrong:
```Python
inp = SpikeGeneratorGroup(1, [0, 1], [0, 10]*ms, dt=10*ms)
S = Synapses(...)
S.delay = [3, 6]*ms # will be interpreted as [0, 10]*ms
```
I don't think the connection of the source's dt to the delays is obvious for the user but I don't really know how to handle this better. Ideally, the dt used for the pathway would depend on the dt of the objects that are affected by the `pre` statement, but since this can be a mix of pre, post, and synaptic variables, it might get complicated... Any good idea?