Back to the main page.

Bug 2584 - ft_selectdata: new version does not correctly select trials from a raw data structure

Status CLOSED FIXED
Reported 2014-05-17 22:15:00 +0200
Modified 2016-06-16 16:38:33 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 major
Assigned to: Jan-Mathijs Schoffelen
URL:
Tags:
Depends on:
Blocks:
See also:

Jan-Mathijs Schoffelen - 2014-05-17 22:15:57 +0200

This is the case when the input data has variable trial length. The cause can be tracked down to line 279 in getdimord, where the values in the variable datsiz are compared to [nrpt nchan ntime]. ntime is based on the number of elements in the data structure's first time-axis, whereas the third element of datsize seems to be based on the longest trial. This comparison fails, and hence the dimord is set to {unknnown}_unknown_unknown, which causes the datfield trial not to be rpt-selected in ft_selectdata. @ Nietzsche: this may have seerious consequences for the changes you made to mous_erf_pipeline, because the trial subselection you built in relied on ft_selectdata performing correctly (now all data fields (e.g. importantly the trialinfo field) are correctly selected, safe the trials). Currently it leads to a mismatch between actual trials and what we think they contain. It can be replicated by: data.trial={1 2 3 [4 5]}; data.time={1 1 1 [1 2]}; data.label={'chan01'}; cfg.trials=[3 4]; dataout=ft_selectdata(cfg,data);


Jan-Mathijs Schoffelen - 2014-05-17 22:21:36 +0200

I changed line 57 in getdimord from ntime = length(data.time{1}) into tmp = getdimsiz(data, 'time'); ntime = tmp(3); % raw data may contain variable length trials This seems to solve the issue. @Robert: agreed? @Nietzsche: let's recompute some stuff


Jan-Mathijs Schoffelen - 2014-05-17 22:26:12 +0200

bash-4.1$ svn commit -m "bugfix - fixed issue that pertained to ft_selectdata to perform poorly with variable trial length raw data, bug 2584" getdimord.m Sending getdimord.m Transmitting file data . Committed revision 9550.


Robert Oostenveld - 2014-05-17 23:01:29 +0200

(In reply to Jan-Mathijs Schoffelen from comment #1) Dat moet ik eens bekijken op een regulier moment. Maar ik heb wel vertrouwen in je zaterdagavond-oordeel. Fijn weekend, Robert


Eelke Spaak - 2014-05-18 08:49:48 +0200

This seems pretty severe, right? Should we email the community? At least I now feel compelled to check all my analysis scripts...


Jan-Mathijs Schoffelen - 2014-05-18 09:56:57 +0200

Regular checking of analysis scripts is something I would recommend anyway ;-). Yet, I think that the scope to the community is rather limited, because I doubt if many people use variable epoch lengths. Informing the community makes sense though.


Chrysa - 2016-06-16 11:46:09 +0200

Hi, I have datasets with variable trial lengths and when I use ft_selectdata with cfg.latency = 'poststim', it gives me as output trials which all have the length of the first trial. Any suggestions?


Jan-Mathijs Schoffelen - 2016-06-16 13:53:28 +0200

false


Jan-Mathijs Schoffelen - 2016-06-16 13:58:37 +0200

with the previous comment I meant that I don't have a suggestion. This 'closed fixed' bug specifically pertained to the selection of trials from a raw data structure, not to a selection of the subset of the time points in the trials of a data structure. I agree that the function's help suggests 'poststim' as an option, but rather than selectdata, I'd use ft_redefinetrial. Still, please feel free to suggest us with a fix for ft_selectdata to improve it's behavior.


Chrysa - 2016-06-16 16:27:30 +0200

thanks for the quick reply. I ll use redefinetrial.


Jan-Mathijs Schoffelen - 2016-06-16 16:38:33 +0200

a contribution to improving ft_selectdata would (although it will be more work for you) be also much appreciated.