Back to the main page.
Bug 2847 - weird interaction of ft_sourceanalysis, ft_selectdata(new and old), and prepare_freq_matrices
| Status | CLOSED WORKSFORME |
| Reported | 2015-02-18 18:22:00 +0100 |
| Modified | 2016-11-29 09:02:51 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Johanna - 2015-02-18 18:22:21 +0100
Created attachment 701 .time subfield Hi all, I've got a fun one for you. I've got the following freq structure. freq = label: {63x1 cell} dimord: 'chan_freq_time' freq: [4 6 8 10 12 14 16 18 20 22 24 26 28 30] time: [1x126 double] powspctrm: [63x14x126 double] labelcmb: {1953x2 cell} crsspctrm: [1953x14x126 double] cfg: [1x1 struct] I called ft_sourceanalysis with this cfg: cfg = grid: [1x1 struct] vol: [1x1 struct] elec: [1x1 struct] method: 'dics' dics: [1x1 struct] frequency: [4 6.5000] latency: [-0.6000 0.6000] The problem is that the freq.time axis is not exactly evenly spaced; for some reason it seems to have 'eps' added/subtracted to some of the .time values. The output of ft_sourceanalysis line 289 [data = ft_selectdata(tmpcfg, data)] is: data = freq: 5 time: -3.6401e-18 crsspctrm: [63x63 double] cfg: [1x1 struct] label: {63x1 cell} dimord: 'chan_chan_freq_time' The reason for the values of the .freq and .time are that in ft_selectdata/makeselection, the mean of the actually used/selected .freq and .time values is taken. That is not a problem per se. But then just further on in ft_sourceanalysis (line 291) the rollback_provenance changes cfg.frequency from [4 6.5] to [4 6] but leaves cfg.latency unaltered. Then just further down, (line 297-300) the 'hack' takes the mean of the cfg.latency and cfg.freq, which is *not* the same as the mean of the actual selected values in the data for the time only, but happens to match for freq. This causes a crash further on, when prepare_freq_matrices calls ft_selectdata(old) on line 197. (Btw, in this case, this call seems unnecessary as the time & freq has already been selected), with cfg.latency=0 but data.time=-3.6401e-18. Error using nearest (line 58) The limits you selected are outside the range available in the data Error in ft_selectdata_old (line 541) toitmp=nearest(data.time,[seltoi(1) seltoi(2)]); Error in ft_selectdata (line 77) [varargout{1:nargout}] = ft_selectdata_old(varargin{:}); Error in prepare_freq_matrices (line 197) freq = ft_selectdata(freq, 'foilim', cfg.frequency, 'toilim', cfg.latency); Error in ft_sourceanalysis (line 461) [Cf, Cr, Pr, Ntrials, cfg] = prepare_freq_matrices(cfg, data); I've included the .time subfield as an attachment, as that is the relevant part. One can see it is not exact by time-[-1.2:.02:1.3]
Johanna - 2015-02-19 11:00:02 +0100
One might ask: how did I end up with a .time axis that wasn't equally spaced values to begin with? I don't know, but just type this into Matlab and see what you get: mean(-.6:.02:.6) mean(-10:.02:10) should be zero but it's not. (on Matlab2013a) I checked with a colleague here (also 2013a) and he had the same weirdness.
Johanna - 2015-02-24 16:01:47 +0100
It could be that bug 2851 fixes this one. Watch this (that) space.