Back to the main page.
Bug 1881 - ft_selectdata_new fails to select frequency limits for coherence data
| Status | CLOSED FIXED |
| Reported | 2012-12-11 17:23:00 +0100 |
| Modified | 2014-05-14 20:08:51 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=2197 |
Diego Lozano Soldevilla - 2012-12-11 17:23:25 +0100
Created attachment 389 toy data after coherence computation using 'coh' method I want to select a frequency range of the coherence spectrum cfg = []; cfg.foilim = [0 90]; f = ft_selectdata(cfg,freqcomp_ecg); freqcomp = labelcmb: {273x2 cell} dimord: 'chan_freq' cohspctrm: [273x466 double] freq: [1x466 double] dof: 340 cfg: [1x1 struct] but ft_selectdata_new chunk the dimord in 'chan' AND 'freq' (line 82; dimtok = tokenize(dimord, '_');). Then 'chancmb' case cannot be found and 'chan' dimord part is used provoking an error because field freqcomp.label is expected: case 'chan' dimsiz(i) = length(varargin{1}.label); Is there a bug in the expected dimord after ft_connectivityanalysis, method='coh' or should I make a case for the dimord: 'chan_freq' + labelcmb? Attached toy data
Roemer van der Meij - 2012-12-12 14:19:30 +0100
bug could be in ft_connectivityanalysis, struct.dimord should possibly be 'chancmb_freq'
Jan-Mathijs Schoffelen - 2014-04-03 21:15:42 +0200
Created a placeholder test function for this one. Note to Robert (in particular): this is a tricky one. Ft_selectdata_new does not support data with labelcmb. In the part of the code that deals with channel selection, it only looks at the label field (hard coded). If I recall correctly, this issue is partially dealt with in ft_selectdata_old by creating a dummy variable, where the labelcmb is temporarily converted into a pseudo-label cell-array (by concatenating as a string the two columns of labelcmb). Then the selections are done, and the appropriate labelcmb is put back in the output. We could do something like this in ft_selectdata_new (I think this will keep the code clean), where somewhere high up in the code we do something like (pseudocode): haslabelcmb = isfield(varargin{x},'labelcmb') haslabel = isfield(varargin{x},'label') if haslabelcmb && haslabel % this is freq data old-style with crsspctrm elseif haslabelcmb && ~haslabel % this is connectivity data with linearly indexed combinations, I think it is fair for the user to expect a meaningful output of the function here % call ft_selectdata twice: once with the data scrubbed from the label-related fields and once with the data scrubbed from the labelcmb related fields % combine the output return; elseif ~haslabelcmb % business as usual: proceed end
Robert Oostenveld - 2014-04-04 09:07:58 +0200
I have over the last few days been working on old/new style representations in relation to sources (see bug 2185) and making extensions to ft_selectdata_new, ft_datatype_source and related functions. Shall I also have a go at this bug, with the recent coding experience still fresh in my head?
Robert Oostenveld - 2014-04-15 18:58:43 +0200
(In reply to Robert Oostenveld from comment #3) The ft_selectdata_newer implementation correctly deals with this.