`time_radius` mechanism

[jbmelander]

@magland My understanding is that in order for a spike to be grabbed and clustered, it has to be free of any spikes within the time_radius in detect_spikes.py - if this is correct, then looking at autocorrelations becomes somewhat uninformative because refractory period violations are specifically excluded from the get-go. Historically, we've clustered all cells, regardless of such violations, then used the autocorrelation as a means of describing how well the clustering behaved. Could you comment on whether my understanding is correct?

[magland]

Yes your thinking is correct. So that's why it's important to choose time_radius to be short relative to the refractory period. I believe the default is 0.5 ms, whereas the refractory period is more like 2ms. So there should always be a 0.5 radius dip, but you can also look for the 2-3 ms dip for validation.

[jbmelander]

@magland Just getting back to getting this working on a few recent datasets after the break - I guess this makes sense, but begs the question: why have an exclusionary time_radius at all? It seems like this method imparts an arbitrary bias and throws away decent spikes. Is there a reason you would discourage one from simply detecting all threshold crossings, then using the refractory period / other metrics as a litmus-test for cluster quality? If there's no compelling reason, I will try sorting a few datasets with and without a time_radius (or time_radius = 0 to characterize any differences.

edit: Is it just a way to enure only a single threshold-crossing is flagged despite the threshold crossing for many samples during the duration of the spike?

[magland]

edit: Is it just a way to enure only a single threshold-crossing is flagged despite the threshold crossing for many samples during the duration of the spike?

Yes that's exactly it.