Back to the main page.
Bug 1390 - data has variable trial lengths, you specified not to accept that
| Status | CLOSED FIXED |
| Reported | 2012-03-23 15:33:00 +0100 |
| Modified | 2012-04-11 16:48:30 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | Macintosh |
| Operating System: | Mac OS |
| Importance: | P3 major |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
n.barascud@ucl.ac.uk - 2012-03-23 15:33:47 +0100
Created attachment 240 minperlength maxperlength When I want to do a timelock analysis, I get the following error : Error using ft_timelockanalysis (line 199) data has variable trial lengths, you specified not to accept that ! Even though my trials have exactly the same length. I included the 2 variables minperlength and maxperlength which are causing the problem at line 199. It seems the difference is of 0.00000000000002 seconds, which is quite surprising since that is way below my time resolution.
Jan-Mathijs Schoffelen - 2012-03-25 20:24:01 +0200
could you upload a small data structure that will let us replicate the problem?
Robert Oostenveld - 2012-03-26 09:26:24 +0200
Dear Nicolas This will be due to an inaccuracy in the numerical representation of the floating point value. See e.g. http://en.wikipedia.org/wiki/Precision_(computer_science) It would help if you would send us the preprocessed raw data structure, if possible with as few trials as possible. We can then replicate it with ft_timelockanalysis([], yourdata) and look at the best way to solve the imprecise time-axis representation. best Robert
Jan-Mathijs Schoffelen - 2012-03-26 09:30:40 +0200
and perhaps also the cfg that was used to read in the data
n.barascud@ucl.ac.uk - 2012-03-26 16:33:33 +0200
(In reply to comment #3) I uploaded a .mat file at the following address : http://www.sendspace.com/file/uk1nqw The file is 36MB. I tried to use only a few trials. Please let me know if I can be of any further help.
Robert Oostenveld - 2012-03-26 17:17:17 +0200
I got the test data and am able to reproduce the problem
Robert Oostenveld - 2012-03-26 18:14:31 +0200
(In reply to comment #5) The following code solves the problem by making the time axes identical again. However, this does not work in case the time axes are shifted relative to each other (i.e. variable trial duration and onset or offset). begtime = zeros(1, length(data.time)); endtime = zeros(1, length(data.time)); numsample = zeros(1, length(data.time)); for i=1:length(data.time) begtime(i) = data.time{i}(1); endtime(i) = data.time{i}(end); numsample(i) = length(data.time{i}); end if ~isfield(data, 'fsample') fsample = 1/mean(diff(data.time{1})); else fsample = data.fsample; end % compute the differences over trials and the tolerance tolerance = 0.1*(1/fsample); begdifference = abs(begtime-begtime(1)); enddifference = abs(endtime-endtime(1)); % check whether they are identical, or close to identical begidentical = all(begdifference==0); endidentical = all(enddifference==0); begsimilar = all(begdifference < tolerance); endsimilar = all(enddifference < tolerance); if false && ~begidentical && begsimilar warning('correcting small numerical inaccuracy of %g seconds in the time axes', max(begdifference)); for i=1:length(data.time) data.time{i} = begtime(1) + ((1:numsample(i)) - 1)/fsample; end elseif false && ~endidentical && endsimilar warning('correcting small numerical inaccuracy of %g seconds in the time axes', max(enddifference)); for i=1:length(data.time) data.time{i} = endtime(1) + ((1:numsample(i)) - numsample(i))/fsample; end end
Robert Oostenveld - 2012-03-27 11:29:30 +0200
After rethinking the correction method, I came up with a more general solution that also works for variable trial-length data. ft_timelockanalysis calls ft_checkdata, which calls ft_datatype_raw, where the fixtimeaxes subfunction deals with a skew in the time axes of up to 1%. The updated version will be released on the ftp server this evening. manzana> svn commit utilities/ft_datatype_raw.m test/test_bug1390.m Adding test/test_bug1390.m Sending utilities/ft_datatype_raw.m Transmitting file data .. Committed revision 5536. PS (for reference): the problem of the time-axis skew resulted from multiple ft_redefinetrial calls, followed by ft_appenddata.
n.barascud@ucl.ac.uk - 2012-03-27 21:12:37 +0200
(In reply to comment #7) I have updated to the latest version and I still have the problem, although minperlength and maxperlength seem equal this time... See the attached datafile : http://www.sendspace.com/file/2ivq8l Apologies for the large file size.
Robert Oostenveld - 2012-03-27 22:30:51 +0200
confirmed, from trial 64 onwards the last timepoint is skewed, but the first is not. That is why the correction is not applied. I now merged my earlier idea (see comment #6) with the previous fix of the code. It works on your second dataset. roboos@mentat001> svn commit utilities/ft_datatype_raw.m test/test_bug1390.m Sending test/test_bug1390.m Sending utilities/ft_datatype_raw.m Transmitting file data .. Committed revision 5548. Please see the last section of ft_datatype_raw to see how it works (and to check whether there are cases where it fails). To be discussed in our FT meeting tomorrow: should we always reconstruct the time axes (regardless of whether a problem is detected)?