help
help > RE: Error in spm_create_vol> unknown datatype NaN
Jul 30, 2014 12:07 AM | Alfonso Nieto-Castanon - Boston University
RE: Error in spm_create_vol> unknown datatype NaN
Hi Bradley,
Thanks for reporting this so thoroughly, I will add that exact check in the next release to give the user some early warning about this particular issue.
In general, the issue of some SPM toolboxes overloading some specific SPM functionality (but then failing to keep that up to date with more recent versions of SPM) is unfortunately somewhat pervasive. When CONN finds any error, one of the things it does is checking to see if any of SPM or CONN functions has been overloaded by any other toolboxes. If they have, you will see below the detailed display of the error message a list of functions that have been overloaded with messages of the form "Warning: ###.m overloaded by version in folder ###"). Often those messages will be innocuous (e.g. if you see something like "Warning: contents.m overloaded by version...", or when the overloaded function is actually compatible with SPM5 or above) but others may be problematic (particularly when, as in your case, the overloaded function was written with SPM2 in mind instead). If you want CONN to perform this check without having to wait until an error pops-up you may simply type
and that will give you a list of SPM or CONN functions that have been overloaded by other toolboxes. In general the way to fix this sort of issues is to check first whether those toolboxes may have a more recent version with a more up-to-date version of the overloaded functions (one that is compatible with SPM5 or above), and if that is not possible then simply reorder the elements in Matlab path to have SPM or CONN take precedence over the toolboxes which include the overloaded functions, exactly as you suggested (this is likely to make the offending toolbox non-functional, but if that toolbox is using SPM2 functionality and you have SPM5 or above chances are that it will not work in any way).
Hope this helps, and thanks again
Alfonso
Originally posted by Bradley Taber-Thomas:
Thanks for reporting this so thoroughly, I will add that exact check in the next release to give the user some early warning about this particular issue.
In general, the issue of some SPM toolboxes overloading some specific SPM functionality (but then failing to keep that up to date with more recent versions of SPM) is unfortunately somewhat pervasive. When CONN finds any error, one of the things it does is checking to see if any of SPM or CONN functions has been overloaded by any other toolboxes. If they have, you will see below the detailed display of the error message a list of functions that have been overloaded with messages of the form "Warning: ###.m overloaded by version in folder ###"). Often those messages will be innocuous (e.g. if you see something like "Warning: contents.m overloaded by version...", or when the overloaded function is actually compatible with SPM5 or above) but others may be problematic (particularly when, as in your case, the overloaded function was written with SPM2 in mind instead). If you want CONN to perform this check without having to wait until an error pops-up you may simply type
conn_checkdistributionfiles
and that will give you a list of SPM or CONN functions that have been overloaded by other toolboxes. In general the way to fix this sort of issues is to check first whether those toolboxes may have a more recent version with a more up-to-date version of the overloaded functions (one that is compatible with SPM5 or above), and if that is not possible then simply reorder the elements in Matlab path to have SPM or CONN take precedence over the toolboxes which include the overloaded functions, exactly as you suggested (this is likely to make the offending toolbox non-functional, but if that toolbox is using SPM2 functionality and you have SPM5 or above chances are that it will not work in any way).
Hope this helps, and thanks again
Alfonso
Originally posted by Bradley Taber-Thomas:
Hi Alfonso,
I just encountered this error that you mention in the FAQ (Troubleshooting: CONN: Error using ==> spm_create_vol>create_vol. "unknown" is an unrecognised datatype (NaN). In my case I traced it back to the recent addition of the WFU PickAtlas to my matlab path, which includes an older and un-renamed version of the spm_type.m script that doesn't allow for the precision specification 'float32' used in conn_process. This old version of spm_type wants just 'float' and returns NaN when given 'float32'.
I fixed the issue by pushing PickAtlas below SPM8 in my path. Perhaps an error throw early on if isnan(spm_type('float32')) would be worth adding too.
Best,
Brad
I just encountered this error that you mention in the FAQ (Troubleshooting: CONN: Error using ==> spm_create_vol>create_vol. "unknown" is an unrecognised datatype (NaN). In my case I traced it back to the recent addition of the WFU PickAtlas to my matlab path, which includes an older and un-renamed version of the spm_type.m script that doesn't allow for the precision specification 'float32' used in conn_process. This old version of spm_type wants just 'float' and returns NaN when given 'float32'.
I fixed the issue by pushing PickAtlas below SPM8 in my path. Perhaps an error throw early on if isnan(spm_type('float32')) would be worth adding too.
Best,
Brad
Threaded View
| Title | Author | Date |
|---|---|---|
| Bradley Taber-Thomas | Jul 29, 2014 | |
| Alfonso Nieto-Castanon | Jul 30, 2014 | |
| Bradley Taber-Thomas | Jul 31, 2014 | |