Back to the main page.
Bug 1504 - ft_timelockanalysis error when averaging response-locked data
| Status | CLOSED FIXED |
| Reported | 2012-06-04 15:27:00 +0200 |
| Modified | 2012-08-23 10:35:09 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | All |
| Operating System: | Linux |
| Importance: | P3 normal |
| Assigned to: | Eelke Spaak |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Tineke Grent - 't Jong - 2012-06-04 15:27:50 +0200
Find attached an example file that produces the error (specified below) when running the indicated code. The error occurs only in some conditions from some subjects. load S06_resp_INCGRLcorr cfg = []; cfg.vartrllength = 1; % response-locked data of diff length S06_resp_avgINCGRL = ft_timelockanalysis(cfg, S06_resp_INCGRLcorr); ERROR: averaging trial 239 of 252??? Error using ==> plus Matrix dimensions must agree. Error in ==> ft_timelockanalysis at 298 s = s + dat; % compute the sum
Robert Oostenveld - 2012-06-04 17:56:47 +0200
Can you attach the problematic dataset, either as mat file or as link to a file e.g. in your Dropbox/Public directory?
Tineke Grent - 't Jong - 2012-06-05 07:48:58 +0200
File that produces the error is available here: https://www.dropbox.com/sh/ad2m0bjtr5m1jnv/OvUZyV2P3x
Eelke Spaak - 2012-06-08 15:24:02 +0200
Note to self (and others): after some investigation, this is most likely due (*again*) to an issue with rounding and the usage of the deprecated data.fsample field.
Robert Oostenveld - 2012-06-08 15:32:24 +0200
you may want to check out bug #498, for which Craig recently committed a fix (with my approval). I hope that fix is not now causing the problem. Please check the dates of the commit and the error
Eelke Spaak - 2012-06-08 15:50:50 +0200
(In reply to comment #4) I checked, and no, this is not related. Fortunately, numerical accuracy does not come into play with this one. The issue is with this line 286: trlshift = round((begsamplatency(i)-latency(1))*data.fsample); It computes the number of zeros that have to be added at the beginning of a trial, if the trial's time axis starts after the total latency window for which the average will be computed. Ideally, the expression passed to round() should always yield an integer number, but, unfortunately, it does not. Thus, round() is used to make it integer. Sometimes, the expression yields values >= 0.5, thus leading to a rounding up. This means that the data used from this trial will be one sample longer than the data from other trials in which the shift was rounded down. Therefore, the sum cannot be computed anymore. My solution is to change line 286 to: trlshift = floor((begsamplatency(i)-latency(1))*data.fsample); so simply always force a round down. It seems to work, and I do think it is valid. Ideally, we would not have a conversion between samples and time points here, but that would require a major overhaul of ft_timelockanalysis. Fixed in revision 5997.