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@gclements.plus.com>