[MINC-development] -O3 breaks N3

[John G. Sled]

Greetings,

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.

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.

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.

cheers,

John

P.S.  Alex, no sabbaticals for me, sorry.


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.
>
>
>