Back to the main page.
Bug 1180 - nanmean does not behave like mean
Status | CLOSED FIXED |
Reported | 2011-11-23 10:53:00 +0100 |
Modified | 2012-01-12 11:26:24 +0100 |
Product: | FieldTrip |
Component: | core |
Version: | unspecified |
Hardware: | PC |
Operating System: | Windows |
Importance: | P3 normal |
Assigned to: | Jan-Mathijs Schoffelen |
URL: | |
Tags: | |
Depends on: | |
Blocks: | |
See also: |
Arjen Stolk - 2011-11-23 10:53:53 +0100
Proposal from Lennart: Now if the dimension of operation is not given, nanmean tries to guess using the code below. This is limited in two ways: dim cannot be higher than 3, and dim cannot be []. Both should be possible (and are in the default 'mean'). OLD CODE if size(in,1) ~= 1 dim = 1; elseif size(in,2) ~= 1 dim = 2; else dim = 3; end; PROPOSAL dim = find(size(in)>1,1,'first'); if this line is used the output of nanmean([]) is NaN, as in mean([]). ALTERNATIVE dim = find(size(in)~=1,1,'first'); this will result in the following behavior. nanmean([]) is [] (not NaN).
Jan-Mathijs Schoffelen - 2011-11-23 11:16:44 +0100
thanks for the suggestion. note that nanmean is just a placeholder for a mex-file. the mex-file should work consistent with matlab's mean. The m-code is the crappy code copied from eeglab. @Arjen: I assign this to you, could you change the code according to Lennart's suggestion, test and commit? thanks. NB: also look at nanstd nanvar and nansum please
Jan-Mathijs Schoffelen - 2011-11-23 11:17:08 +0100
and kindly ask Lennart to create a bugzilla account
Lennart Verhagen - 2011-11-23 11:48:40 +0100
nanmean is already a placeholder for a mex-file? Right, I had no idea (I didn't even check for that). I just noticed the difference between the nanmean I wrote myself and the one I found in FieldTrip. Thanks for your help! On another note, these placeholders usually have a line trailing in the comments (% Built-in function.). Is this also the case for FieldTrip mex-files?
Jan-Mathijs Schoffelen - 2011-11-23 12:24:46 +0100
@On another note, these placeholders usually have a line trailing in the comments (% Built-in function.). Is this also the case for FieldTrip mex-files? Good point. Well, actually no. We decided to mex the nanmean because the overloaded m-file currently is very memory inefficient. If your implementation is less clunky we could consider replacing the code (with your permission of course). Also, note that the nanXXX are not built-in functions but are in the statistics-toolbox. Irrespectively it's worthwile to include some documentation in the function that it also exists as a mex-file.
Boris Reuderink - 2012-01-03 12:33:15 +0100
Changed bug status to assigned to reflect JM prosaic assignment.
Arjen Stolk - 2012-01-11 11:02:09 +0100
Added to documentation of private/nanmean, nanstd, nansum, nanvar: Note: all nanXXX.m functionalities are implemented through mex-files that are more memory efficient. The code in the MATLAB mfile is not necessarily identical to that in the max-file. Nanstandardise does not have a related mex-file. But I changed its first line from 'function standardise' to 'function 'nanstandardise', compatible with the functionname.
Arjen Stolk - 2012-01-11 11:02:33 +0100
Fixed, see below/above.
Jan-Mathijs Schoffelen - 2012-01-11 15:36:19 +0100
Still, Lennart's suggestion is still a very good one, i.e. if dim is not defined as an input argument, let dim = find(size(in)>1,1,'first');
Jan-Mathijs Schoffelen - 2012-01-11 15:41:03 +0100
Still, Lennart's suggestion is still a very good one, i.e. if dim is not defined as an input argument, let dim = find(size(in)>1,1,'first');
Jan-Mathijs Schoffelen - 2012-01-11 15:41:34 +0100
changed in revision 5128