[MINC-development] experiments with EBTKS and N3

[Vladimir S. FONOV]

Hello,

Let me explain my previous email in more details.
The problem with N3 came from sloppy c++ wrapper around FFT library.
There are might be other potential problems with this c++ library,
because it its mainly unsupported and have been tweaked around many
times also there are no documentation and no regression tests for it.

The real improvement would be to address problems mentioned above,
for example by going over code and making test cases for all
functionality of EBTKS.

The possible performance improvement of replacing existing Fft code
with FFTW is going to be negligible, at least for N3 (and I think this
is the only place where it is used currently).

On Mon, Aug 20, 2012 at 9:00 AM, Jordi Gutiérrez Hermoso
<jordigh at octave.org> wrote:
> On 12-08-19 10:49 PM, Andrew Janke wrote:
>
>> On 19 August 2012 22:11, Jordi Gutiérrez Hermoso
>> <jordigh at octave.org> wrote:
>
>>> I know FFTW from my GNU Octave work, and I think I could hook it
>>> in. A caveat: FFTW is GPL, so the resulting package would have to
>>> be under GPL-compatible terms. The original McGill license is fine,
>>> but if people want to grab it and make non-free derivatives, they
>>> won't be able to do it if we link to FFTW.
>>
>> Indeed, my approach to this a while ago was to write this:
>>
>>     https://github.com/BIC-MNI/mincfftw
>
> That link seems broken. But I assume you're attempting to write a GPL
> wrapper? The FSF's legal opinion is that this doesn't exclude MINC
> from its GPL obligations:
>
>     http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLWrapper
>
> Since the FSF wrote the GPL, I would assume a court would side with
> this opinion. People keep wanting to get around the GPL by writing
> wrappers. This doesn't achieve the purpose.
>
>>> If this is acceptable, and I hope it is, I'd be happy to work on
>>> the FFTW integration.
>
>> More than happy for your help. So if possible the way I'd approach
>> would be to remove the dependency on fft's in EBTKS and instead
>> fork a system call to mincfft in either N3 or EBTKS.
>
> Since mincfft really serves no purpose, can we just directly call
> FFTW? Is there still a reason to keep the GPL out of MINC?
>
> On 20 August 2012 01:01, Vladimir S. Fonov <vladimir.fonov at gmail.com>
> wrote:
>> I would very much prefer, if we replace EBTKS with something more or
>> less standard, for example GSL.
>
> The GSL's Fourier transforms are based on the old Netlib FFTPACK
> routines. They are ok, I guess, but FFTW *is* standard. The only
> reason to not use FFTW is a distaste for the GPL. Scipy for example
> used FFTW until they were unhappy with the GPL status and they
> switched to FFTPACK.
>
> So, the only reason you might have for not using FFTW also applies to
> the GSL, which is also GPL'ed. So the GSL gives no advantage over
> FFTW.
>
>> I don't really see any advantage of switching internal C routine for
>> FFT computation with FFTW.
>
> FFTW is a great package. It's fast, it's flexible, it's standard.
> There are good reasons to use it.
>
>> P.S. Regarding license - interesting read in
>> https://github.com/BIC-MNI/EBTKS/blob/develop/templates/MatrixSupport.cc
>> , starting at " NOTE: This routine uses at least 2 patented
>> algorithms"
>
> It look like the patents are at least 20 years old. They've likely
> expired by now. But if they haven't, all the more reason to replace
> this code. Having non-free code of dubious legal status is worse than
> having forever free code.
>
> - Jordi G. H.
> _______________________________________________
> 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