Back to the main page.

Bug 2680 - ft_timelockanalysis does not compute minperlength correctly

Reported 2014-08-30 23:02:00 +0200
Modified 2015-01-12 09:20:46 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 normal
Assigned to: Jan-Mathijs Schoffelen
Depends on:
See also:

Craig Richter - 2014-08-30 23:02:42 +0200

Craig Richter - 2014-08-30 23:06:18 +0200

At line 155 of ft_timelockanalysis the minperlength is computed. When multiple trials are used of the same length, this leads to a [start end] for minperlength that does not make sense since the starting value is selected as the start time of the final trial, and the end point is selected as the end time of the first trial. This then triggers the error message at line 167.

Craig Richter - 2014-09-02 21:31:27 +0200

To add a bit more info that I determined. It seems that this outcome is due to each trial having a different time axis (though the same length) after using ft_redefinetrial to cut one long (resting state) trial into equal length snippets. Since this operation preserves the time-axis of the original trial, ft_timelockanalysis doesn't not seem to treat this situation in the right way. I'm not sure if the best approach is to give a common axis to the output when using ft_redefinetrial to create sub-trial of a given length from a single-long trial, or that ft_timelockanalysis should disregard the time-axis. Nonetheless, this computation is indeed giving the wrong result in determining that these trials are of different length, when they are indeed of the same length.

Jan-Mathijs Schoffelen - 2014-09-10 13:55:14 +0200

expected behavior of a sequence of calls to ft_redefinetrial and then ft_timelockanalysis would yield the same data again. to be tested in a script irrespective of this the minperlength detection should be made correct

Jan-Mathijs Schoffelen - 2014-09-10 14:48:34 +0200

My version of ft_timelockanalysis does not have an error message on line 167. I created a test function that behaves the way I expect it to do, i.e. if a single long trial is cut into pieces, and subsequently ft_timelockanalysis is called with cfg.vartrllength = 2; the original data is returned. Am I missing something? Is it the confusion that the 'same length trials' actually should mean 'same length trials with identical time axes'?

Craig Richter - 2014-09-10 14:56:25 +0200

Exactly, they are the same length, thus they satisfy the criterion and thus should not require option 2 for cfg.vartrllength. It seemed to me based on the description that I should use option 1, but since the time-axes are not the same, it should be option 2. I realize that for computing an average over the trials, this wouldn’t make a lot of sense, but since I was interested in computing the covariance, it threw me for a loop.

Jan-Mathijs Schoffelen - 2014-09-10 15:10:52 +0200

bash-4.1$ svn commit -m "documentation - updated ft_timelockanalysis to be more explicit in what is meant with 'equal length trials', bug 2680" ft_timelockanalysis.m Sending ft_timelockanalysis.m Transmitting file data . Committed revision 9785.