[GRASS5] gmath.h

[Glynn Clements]

Brad Douglas wrote:

> I've noticed that several functions in gmath.h lack the G_ prefix.  Is
> this by design?

No. Nothing in the gmath library is by design. AFAIK, all of the
functions in that library were originally part of individual modules. 
If another module wanted to use the same function, the code was copied
into the new module.

Some of those functions were moved into libgis, and eventually the
gmath library was created and various common mathematical functions
were moved into it from both libgis and the various modules.

> Is it okay if I add the prefix (or G_math_) where applicable?

It's fine by me.

> I'm finishing the cleanup of lib/gmath and this is the last issue that
> remains.

There is another significant issue: the fft() interface.

GRASS used to have its own FFT routine, before we decided to use FFTW
instead. Most (or all) of the existing users of the fft() function are
converting data to and from the format which the old fft() function
used, and the new fft() function is converting it to or from the
format which FFTW wants.

This is rather inefficient to say the least.

The key points are:

1. The old fft() function used separate arrays for the real and
imaginary components, while FFTW uses an array of fftw_complex values
(i.e. interleaved real and imaginary components).

2. The old fft() function required the array dimensions to be powers
of 2, while FFTW doesn't have this requirement.

The net result of this is that code which uses fft() is wasting a lot
of memory. In the worst case, it can use almost 8 times as much memory
as is actually necessary. Padding each dimension to the next power of
2 can result in a near-fourfold increase, while storing two copies
(the separate real/imaginary arrays plus the interleaved array)
doubles it again.

-- 
Glynn Clements <glynn at gclements.plus.com>