Back to the main page.

Bug 1777 - ft_spike_xcorr nlags/size of .xcorr field

Status NEW
Reported 2012-10-10 14:42:00 +0200
Modified 2015-07-15 13:06:30 +0200
Product: FieldTrip
Component: spike
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P3 normal
Assigned to: Bart Gips
URL:
Tags:
Depends on:
Blocks:
See also:

Bart Gips - 2012-10-10 14:42:12 +0200

Problem: ===================================== ft_spike_xcorr creates a stat.xcorr field of length cfg.maxlags*2, even though the help section says 2*maxlags+1. The 2*maxlags+1 makes sense: the result will give you -maxlag:maxlag, so maxlag lagging to maxlag leading. So changing line 198: s = zeros(nChans,nChans,2*nLags); to s = zeros(nChans,nChans,2*nLags+1); (together with the other changes needed) makes sense. ====================================== Secondly: A cross-correlation of two signals can only be of length equal to the sum of the lengths of the two signals minus 1. I.e. Signal A: 1 x M Signal B: 1 x N xcorr(A,B)= 1 x (M+N-1) So if the user would want a full xcorr the user should be able to select this. Right now this is not the case. This could be solved by either changing line 198 again: s = zeros(nChans,nChans,2*nLags-1); (but this would disregard the first point I made) or by adding a special case e.g. if nLags>length(spike.trial{n}) s = zeros(nChans,nChans,2*length(spike.trial{n})-1); end =========================================


Joscha Schmiedt - 2015-07-15 13:06:30 +0200

I agree that this is a problem. At the moment it's also not clear from the documentation what the lags actually mean, center of the bins or edges, and how the maxlag and binsize options make up the computation bins. The documentation says stat.lags = (2*nlags + 1) vector with lags in seconds. The actual output is called stat.time and does not reach until cfg.maxlag but until cfg.maxlag-cfg.binsize/2.