[MINC-development] -O3 breaks N3

[John G. Sled]

Vlad,

N3 version 1.0 included a test suite and reference data computed on the 
SGI.  My recollection is that it would report differences at the level 
of 1e-5 for intel systems.  I think the test suite was dropped in the 
move to standardize the build processes across the different minc 
packages.  I have not been following the recent revisions too closely, 
but I gather there have been some minor algorithmic changes introduced 
that could explain larger deviations from the original results.  With 
respect to -O3, I expect you are correct about there being problems with 
const pointer aliasing.  The for_less macro that was mentioned doesn't 
sound like an example of that though.

cheers,

John



On 12-04-14 12:33 PM, Vladimir S. FONOV wrote:
> Hello,
>
>
> On Sat, Apr 14, 2012 at 11:50 AM, John G. Sled<jgsled at phenogenomics.ca>  wrote:
>> I do not expect it will be too much work to divorce N3 from the EBTKS.  The
>> data types that N3 uses from EBTKS are the matrix and string functions.  I
>> expect the latter are trivially replaced by (now) standard library calls.
>>   The matrix functionality that is needed is allocation and resizing of
>> arrays, matrix multiplication and inversion, 1D fft, as well as exposing the
>> numerical data as a pointer.  The matrix inversion could be switched to
>> lapack calls, since this is already a dependency.  As with most such
>> projects, I expect much of the work will go into convincing oneself that the
>> revised code is not broken.
> Well, there are no tests to convince one that the current
> implimentatation is not broken either. I remember an experiment that
> Claude performed a couple of years ago , which involved improving N3 .
> Unfortunately it completely changed the results of cortical thickness
> analysis that Alan's group was doing at the time.
>
>
>> With respect to the -O2 vs. -O3, I think that requiring the code be compiled
>> with -O2 is a reasonable requirement.  Based on the discussion, it sounds
>> like -O3 does not fully support standard C.  I do not think reducing the
>> code to use that subset of the language which is compatible with -O3 is time
>> well spent.  The evolution of the language and incomplete implementation by
>> compilers has been  an ongoing headache for this code base.
> I believe that results  should not change regardless of either O3 or
> O2 and it is not the matter of supporting standard C.  I suspect it is
> really the  results of circumventing semantics of standard C like
> passing some const pointers and then casting it to a non-const pointer
> etc.
>
>> With respect to the idea of switching N3 to be a wrapper for N4, this would
>> not hurt my feelings.  I gather that the implementation of splines is much
>> quicker in N4.   However, since the implementation is similar but not
>> identical to N3, this would represent a significant departure from the
>> present discussion of how to preserve byte for byte reproducibility of old
>> results.
> Current version 1.12 does not produce the same results as 1.10.1 or 1.11
> and apperently it also depends on the version of the compiler used.
> I can imagine that the old results produced on a SGI machines are now
> completely unreproducable on intel desktops. Even if we manage to
> compile same version of N3 that was used at the time.
>
>
>> On 12-04-14 9:20 AM, Vladimir S. FONOV wrote:
>>> Hello Everybody,
>>>
>>> On 4/14/2012 6:47 AM, Alex Zijdenbos wrote:
>>>> Re: (1), I think that ideally EBTKS would be written out of the
>>>> MINC/etc codebase altogether. I suspect that would primarily affect
>>>> N3, so it at least it would require a substantial rewrite of N3.
>>>> However, I do think there may be a shortcut to be taken here, which
>>>> would be to leave the code pretty much as it is, but just work the C++
>>>> template pieces out of it. That could probably be done with a
>>>> manageable amount of copy/paste/search/replace; basically
>>>> instantiating the templates (only) for the types needed (which
>>>> probably aren't many in the end). Question is, who? Does John need a
>>>> sabbatical perhaps? ;-)
>>>
>>> my first instinct would be to replace that elegantly written piece of code
>>> with something that is supported by community and still under development,
>>> for example GSL.
>>>
>>> Second idea would be to replace N3 with N4 (
>>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.0/Modules/N4ITKBiasFieldCorrection
>>> ) and just write a wrapper scripts like nu_correct and nu_evaluate that
>>> would mimic behavior of N3 using calls to N4 and ITK.
>>>
>>>
>>>
>> _______________________________________________
>> MINC-development mailing list
>> MINC-development at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>
>