Back to the main page.

Bug 1398 - FT nansum do not work on a vector of booleans

Status CLOSED FIXED
Reported 2012-03-29 11:01:00 +0200
Modified 2019-08-10 11:56:58 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P2 normal
Assigned to:
URL:
Tags:
Depends on:
Blocks: 1560
See also:

Jörn M. Horschig - 2012-03-29 11:01:36 +0200

just try with a=[true true false]; nansum(a) and make sure that the nansum is the FT version, the Matlab version correctly returns 2 as an answer


Jan-Mathijs Schoffelen - 2012-03-29 11:05:30 +0200

a vector of booleans never contains nans, so why nansum it? does the stats-toolbox version support booleans?


Robert Oostenveld - 2012-03-29 13:22:34 +0200

> correctly returns 2 as an answer so the more true statements you make, the more truer your story becomes? ---- One aspect would be to check on inputs and always give an error on inappropriate inputs. E.g. what happens with x = @plus nansum([x x]) Another is to type convert. Don't know whether that is desired.


Eelke Spaak - 2012-04-02 10:53:40 +0200

The stats toolbox version of nansum supports logicals, since it is implemented in an .m-file and not a mex-file. For the m-file, it is trivial to support logicals, since sum() supports logicals as well. I agree with JM, people wanting to sum logical arrays should just use sum(), since a logical can never be nan.


Boris Reuderink - 2012-06-13 12:47:14 +0200

Hmm. Odd one indeed. Matlab automatically convert a literal array with nans to double: >> class([true true false nan]) ans = double Since Matlab's nansum and sum already seem to convert booleans to integers, perhaps it is wise to add type conversion to nansum, but with a warning.


Robert Oostenveld - 2012-06-13 17:54:45 +0200

if the type is intXX, uintXX or bool, it can just sum and does not have to care about the nans. I would do a switch statement on http://www.mathworks.nl/help/techdoc/apiref/mxgetclassid.html and http://www.mathworks.nl/help/techdoc/apiref/mxclassid.html Note that you also should deal with this one ;-) >> nansum('nan') ans = 317 >> which nansum /Applications/MATLAB_R2010a.app/toolbox/stats/nansum.m which is of course the same case as >> nansum('abc') ans = 294


Robert Oostenveld - 2012-06-13 17:57:23 +0200

... and did you know that >> nanvar('nan') ans = 56.3333 So please fix all of manzana> ls private/nan*.m private/nanmean.m private/nanstd.m private/nanvar.m private/nanstandardise.m private/nansum.m [[or at least catch the error if the input to the nanXXX mex file is unexpected]]


Boris Reuderink - 2012-06-21 13:50:04 +0200

Added unit tests for nansum, nanmean, nanvar and nanstd: http://code.google.com/p/fieldtrip/source/detail?r=6104


Boris Reuderink - 2012-07-26 15:12:54 +0200

Worked quite some hours on the nan* functions. Most data types work now as expected for nansum (other stat fuctions are very easy to port). Handling of complex numbers still needs to be integrated. See https://github.com/breuderink/fieldtrip/commits/nanstat .


Boris Reuderink - 2012-09-20 16:02:16 +0200

Update: worked quite hard on nansum. Was bitten by a "Heisenbug" caused by Microsoft's implementation of "isnan", which did not work as it should — for very unclear reasons. Fix; #define isnan(x) !(x==x) Very odd. Microsoft's version yielded true for characters and integers, despite that NaN cannot be represented for these types. Also, there was interplay between the result of nansum, and whether the code was run through xUnit or not, which should not matter. Now that this is fixed, the code is quite neat and mature. Handling of complex numbers still needs to be implemented.


Boris Reuderink - 2012-09-20 16:06:00 +0200

And oh, to confuse things even more: Microsoft als has a _isnan() in float.h, which does work as expected.


Robert Oostenveld - 2012-09-20 16:08:03 +0200

(In reply to comment #9) something along the BBM lines like this? if isnan(x) && ~isnan(xx) the problem is not computable, go into infinite loop else give a smart answer, like a turing machine is supposed to do end


Boris Reuderink - 2012-09-24 17:57:04 +0200

I have had the infinite loops.. and maybe the smart answer as well. Now, complex valued arrays are properly handled, and I have adapted the nan* friends as well. TODO: - Check if new interfaces (especially the not-nansum ones) are compatible with MATLAB's. Note the weight argument in var. - Disable potentially remaining debug output. - Merge!


Boris Reuderink - 2012-09-24 17:57:34 +0200

For the WIP code, see https://github.com/breuderink/fieldtrip/commits/nanstat


Boris Reuderink - 2012-09-27 14:16:55 +0200

Added cleaned up and tested on both Windows and Linux 64-bit.


Boris Reuderink - 2012-09-28 14:54:01 +0200

Added OSX mex files, and re-enabled auto-sync and manually synced all files. See SVN revision 6577–6597.


Boris Reuderink - 2012-11-02 13:29:58 +0100

I am no longer working on FieldTrip. Hence, I donate all my bugs to the joint development user.


Robert Oostenveld - 2019-08-10 11:56:58 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue describing the issue on https://github.com/fieldtrip/fieldtrip/issues.