Back to the main page.
Bug 3034 - ft_selectdata does not take nanmean avgoverdims
Status | CLOSED FIXED |
Reported | 2016-01-07 22:33:00 +0100 |
Modified | 2016-01-14 21:25:07 +0100 |
Product: | FieldTrip |
Component: | preproc |
Version: | unspecified |
Hardware: | PC |
Operating System: | Mac OS |
Importance: | P5 normal |
Assigned to: | Jan-Mathijs Schoffelen |
URL: | |
Tags: | |
Depends on: | |
Blocks: | |
See also: |
Arjen Stolk - 2016-01-07 22:33:31 +0100
If there a reason for not having ft_selectdata use nanmean? See line 543: data.(datfield) = mean(data.(datfield), seldim); And also line 1269: function x = cellmatmean(x, seldim) if iscell(x) if seldim==1 for i=2:numel(x) x{1} = x{1} + x{i}; end x = {x{1}/numel(x)}; else for i=1:numel(x) x{i} = mean(x{i}, seldim-1); end % for end else x = mean(x, seldim); end
Robert Oostenveld - 2016-01-08 08:54:14 +0100
I think the reason is that on default we want to be on the safe side, which means that chan-time-freq points with missing values (which is usually meant with "nan") are retained as missing in the output. But I can imagine the use of nanmean. Should we consider implementing it as cfg.avgoverxxx = yes/no cfg.nanmen = yes/no and then add a line such as if strcmp(cfg.nanmean, 'yes') average = @nanmean; else average = @mean; end and then inside the functions replace all calls to the mean() function by calls to average(). Are mean and nanmean compatible with respect to input arguments?
Arjen Stolk - 2016-01-08 09:00:12 +0100
(In reply to Robert Oostenveld from comment #1) I see. Yes, I believe they're interchangeable (unlike std and nanstd). Sounds like a useful option to me. For instance, when you have timelock data with a trial field, and unequally sized trial lengths (thus nan-padded for shorter trials, courtesy of cfg.vartrllength = 2), avgovertime results in nothing but nans.