Back to the main page.
Bug 2022 - nanmean and nansum .mex files bug crashes matlab
Status | CLOSED FIXED |
Reported | 2013-03-01 12:16:00 +0100 |
Modified | 2014-01-29 13:28:37 +0100 |
Product: | FieldTrip |
Component: | core |
Version: | unspecified |
Hardware: | Other |
Operating System: | Linux |
Importance: | P3 critical |
Assigned to: | Eelke Spaak |
URL: | |
Tags: | |
Depends on: | |
Blocks: | |
See also: |
Hanneke van Dijk - 2013-03-01 12:16:22 +0100
Created attachment 430 crashdump file I found the error in utilities/private/ when running statistics with averaging over freqs and time. In nanmean.m we discovered that there is a t where there should be an x (because there is no t in the input, or it was the other way around). What's wrong with nansum I don't remember anymore, but the documentation is copied from nanmean and is not explaining nansum. When we fix the t and x error in the nanmean.m and remove the .mex files for nanmean and nansum, statistics (with averaging over freqs and time) runs perfectly. I have included the matlab_crash dump Groetjes Hanneke
Hanneke van Dijk - 2013-03-01 12:17:12 +0100
By the way we are running matlabR2012b.
Johanna - 2013-03-01 12:24:03 +0100
see bug 2011. does that answer it for you? What system are you running on?
Eelke Spaak - 2013-04-05 11:22:01 +0200
*** Bug 2072 has been marked as a duplicate of this bug. ***
Eelke Spaak - 2013-04-16 14:10:48 +0200
(In reply to comment #2) this is a different error I'm marking this as higher importance, we should really fix those mexfiles.
Jan-Mathijs Schoffelen - 2013-04-17 14:25:21 +0200
discussed in FT-meeting: -revert back to JM's version of the c-code, which seemed a bit more stable. -address remaining issues in this code (e.g. dealing with booleans).
Eelke Spaak - 2013-05-02 15:37:21 +0200
This should now be fixed (revision 8086/8087). I reverted to the last well-working mex files, and improved them a bit. Specifically, whenever input is not single or double precision float, but still numeric/char/logical, the builtin non-nan variant of the command is called. This is safe, because only doubles or singles can ever be nan, nan is not a possible value for logical or char. Note that I have only compiled for Linux 64-bit. Other platforms still need to be done. Jörn, could you help for Windows 32/64? And Robert for Mac 32/64?
Eelke Spaak - 2013-05-02 15:37:55 +0200
(In reply to comment #6) And of course, forgot to mention, nan is also not a possible value for all the int/uint types.
Jörn M. Horschig - 2013-05-03 08:02:16 +0200
working on it - does this also count for all nan* file (I saw that they all got deleted from svn)?
Jörn M. Horschig - 2013-05-03 08:20:49 +0200
I added nanmean, nanstd and nanvar. I am not sure about others like nannumel, nanvar_base, nanaccum. Let me know if they need to be added.
Eelke Spaak - 2013-05-03 08:34:26 +0200
(In reply to comment #9) Great! I deleted nanvar_base, nanaccum, and nannumel, as they were only helper functions for Boris' implementation of the end-user nan* functions.
Eelke Spaak - 2013-05-04 12:42:37 +0200
(In reply to comment #9) Could you also do nansum? Danke!