On 28 August 2016 at 06:59, Knut J Bjuland knutjorgen@outlook.com wrote:
I found this paper about named “Reproducibility of neuroimaging analyses across operating systems” (Glatard et al., 2015). There were differences in cortical morphometry like cortical thicknes between images proscced in the same version of freesurfer with different version of Linux or glibc for Freesurfer, and according to the paper, it was caused by how different version of glibc handles small single precssion floating numbers. I have therefore some questions.
Are there plans for freesurfer to use double floating numbers in steps that may be affected by numerical stability? Or can this problem be solved by using staticall linking glibc into Freesurfer?
Freesurfer does use double precision numbers extensively on the CPU side (on the GPU side of things, I generally went back to singles). The issue is not one of numeric stability, and going to all-double (or all-quad) would not remove the differences - they are fundamental to how floating point arithmetic works. Put simply, for floating point numbers: a+(b+c) != (a+b)+c Any attempt to ignore this fact is going to come to grief at some point.
Freesurfer often has to do things such as "find voxels exceeding threshold" or "find most likely label for voxel." Operations like this are always going to be vulnerable to differences in the least significant bit.
Speaking from a numerical background (I have no experience in neuroscience), I would suggest embracing this behaviour rather than trying avoid it (arguably a fool's errand). Use the differences between different library versions (not just libc, but all the other numerical libraries Freesurfer uses) to provide an estimate of the confidence levels/error bounds on your Freesurfer runs. If your conclusion depends critically on using version x.y.z of a library, rather than x.y.z+1, then unless you can point to a specific bug in the library, you probably don't really have a conclusion.
Regards,
Richard