Hamish wrote:
> > I'm wondering whether those functions (matrix/vector alloc/free)
> > really belong in the gmath library. It can be quite a heavy
> > dependency, optionally requiring FFTW, BLAS and LAPACK.
> >
> > The significance of this is that, if a user installs a binary GRASS
> > package, and they don't have FFTW (or their version of FFTW is
> > incompatible with the one used to build the gmath library), it won't
> > just be the handful of programs which need FFTW which fail to work.
Markus:
> In some cleanup activity we moved it to gmath. Later, gmath
> got enriched with FFTW support and such.
>
> It should possibly go back to libgis (in GRASS 7).
.... or move FFTW stuff etc. into an "advanced_math" library.
As for FFTW specifically, it would probably be better to just abandon
the GRASS wrapper and have the modules call FFTW directly.
The wrapper exists because GRASS originally had its own FFT
implementation, which was replaced with FFTW to eliminate potential
copyright uncertainties with the FFT code.
Changing the existing function to a wrapper around FFTW was the
quickest way to implement this change, but certainly not the most
efficient.
First, the GRASS interface uses separate real and imaginary arrays,
while FFTW uses a single array of complex values (i.e. interleaved
real and imaginary parts).
Second, the built-in FFT was limited to powers of two for the array
size, while FFTW doesn't have this restriction.
Consequently, any code which uses the fft() function first expands the
data to meet the (obsolete) power-of-two requirement, then a copy of
the expanded data is made to match the FFTW format (even though the
data could invariably have been generated in this format to start
with). The end result is wasted memory and CPU cycles.
--
Glynn Clements <glynn@gclements.plus.com>