Repository navigation
isc: how should we handle NaNs when pairwise=False? #398
Description
Currently the leave-one-out (pairwise=False) ISC and ISFC functions use np.mean to average across N–1 subjects prior to computing correlation with the left-out subjects. This means a NaN for any single subject will kill the mean time series. NaNs may occur during z-scoring prior to ISC computation because some voxels have zero variance—especially at edges of the brain due to limited FoV for EPI scans and susceptibility dropout (especially bad for old datasets). See attached figure where the colored values indicate how many subjects (out of 20 total) have NaNs for a given voxel. Currently all colored voxels in this figure would yield a NaN after ISC computation. I propose using np.nanmean rather than np.mean when computing the average time series across N–1 subjects so that NaNs can be accommodated. For example, in the case corresponding to the attached figure, I may opt to completely exclude all voxels where 50% or 90% or more subjects have NaNs, but I would still like to include voxels where only a couple subjects have NaNs. This would require some special care by the user, so I wanted to run this past others. Not sure how accepting of NaNs we should be... I suppose we could also have a keyword argument like allow_nans=True for flexibility (or even allow_nans=.9). Any thoughts on this? @mihaic @qihongl @manojneuro
Activity
snastase commentedon Jan 7, 2019
After some offline conversations, seems like Hasson Lab convention is to threshold to keep only voxels where e.g. >= 80% of subjects have non-NaN values and use
nanmean. There may be other reasons or methods for thresholding, so I'm inclined to leave that up to user prior to ISC computation and not build this sort of thresholding into the function. So I guess this comes down to either: (a) simply changenp.meantonp.nanmeanand warn the user in documentation; or (b) include a keyword argumentallow_nansthat isFalseby default but can be toggled on to accommodate NaNs. Let me know what you think and I can work up a PR.manojneuro commentedon Jan 7, 2019
mihaic commentedon Jan 7, 2019
I think the default should follow the literature. If thresholding is not compute intensive, I would add a
thresholdparameter with a default value of 80% and an option to turn it off by setting it toNone. This would allow alternative thresholding by the user. I would addallow_nansand set it toTrueby default.