[MINC-development] -O3 breaks N3

[Vladimir S. FONOV]

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



-- 
Best regards,

 Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com