On Sun, 21 Feb 2016, R Edgar wrote:
On 21 February 2016 at 22:33, zkaufman@nmr.mgh.harvard.edu wrote:
Intolerable differences have not been found. They are always minor <%5 and their source can come from several places. For example, different compilers (or even different versions of the same compiler) can have different sorting behavior when presented with objects that have equivalent comparators. Others occur with data structures being written/read to disk (Im still trying to fully understand those). As well as a host of other potential differences as you mention below.
However, no cases have been found to fall outside expected and accepted tolerance levels.
That's a relief, but it makes me wonder about another point (and please understand that I'm making the following statement from a position of ignorance as to how Freesurfer is used in practice):
Shouldn't differences like this be embraced? They are giving a measure of the error bars which should be applied to any results.
I'd be interested in hearing people's thoughts about this.
Going back to smaller and concrete things, I'm also curious as to the differences you say are creeping in when IO occurs. Is this happening for formatted or binary I/O?
Before commenting I want to state that this sub-thread is IMHO off-topic, since I don't think it shouldn't (theoretically) have to do anything with dynamic linking of internal code ...
IO issues also Z K mentioned also sounded interesting to my ear ;) smells like alignment issues or uninitialized memory somewhere -- valgrind could be of great help here... eventually, whenever a proper debian package of freesurfer would see a daylight and there would be some unit-tests, building/testing on exotic platforms such as big-endians (powerpc, sparc, s390x) and the ones with stricter alignment requirements (iirc armhf) can help to pin down locations of such bugs since then e.g. 0x1 becomes 0x10000 and thus sticking into your face ;) (we have encounter such ones from time to time with e.g. numpy and scipy)