[GRASS-dev] GRASS inefficiency and FFTW

[Dylan Beaudette]

On Monday 26 February 2007 01:21, Hamish wrote:
> Stefano De Paoli wrote:
> > Given this problem I started to wonder whether this example fit with
> > the issue that Free Software is primarly about so called "freedom" and
> > not about efficency. As many many Open Source advocates usually say.
> >
> > Which means that an inefficient solution has been introduced in GRASS
> > in order to maintain the integrity of the GPL license.
>
> Efficiency is a relative term.
>
> Current fft translation code gets the job done faster than the
> alternative NR version, as the NR solution can't be used at all.
>
> We could optimize the software to be very efficient in some aspects
> (fft), but we would have to compromise in others (legality).
> We must balance the efficiency of a module's resource needs versus
> of the efficiency of the greater project development (both code and
> social*).
>
> [*] see discussions covering relicensing the GRASS 6 vector lib under
> the LGPL; some devels would not continue to contribute under those
> conditions. (FWIW I wouldn't mind e.g. dglib network routing becoming
> LGPL, but some of that is GPL (c) FSF so that's not really probable)
>
>
> the classic FOSS priorities are, in order of importance:
>   0. code is legal. (it can be used at all)
>   1. code works.
>   2. code is easy to understand and maintain.
>   3. code is optimized.
>
>
> I would encourage you to search the archives for threads concerning
> Radim's v.in.dwg vs. Huidae Cho's v.in.dxf port. Similar issues apply.
>
>
>
> best of luck,
> Hamish
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

Hmm, it doesn't look like there are all that many files actually calling or 
defining fft():

/include/grass/gmath.h
imagery/i.fft/fftmain.c
imagery/i.fft/local_proto.h
imagery/i.ifft/ifftmain.c
imagery/i.ifft/local_proto.h
lib/gmath/del2g.c
lib/gmath/fft.c
raster/r.surf.fractal/frac.h
raster/r.surf.fractal/spec_syn.c


Does anyone gave a general idea of the tasks which would need to be completed 
to remove the backwards-compatibility layer? Perhaps a couple people can 
perform these tasks. I am not a great programmer, but if the tasks are fairly 
simple I might be able to help, with some oversight.

cheers,

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341