Back to the main page.

Bug 1881 - ft_selectdata_new fails to select frequency limits for coherence data

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
Depends on:
See also:

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.

Robert Oostenveld - 2014-05-14 20:08:51 +0200

closed several of my bugs that have been resolved