for your info: ch. 11 mbe: fast fourier transforms

> OK, great. Just for the record, I'm going to make the fft functions
> handle lists as well as arrays, and also handle a single argument
> from which real and imaginary parts are extracted. I'm guessing
> these changes will make it easier to use.
>
> I am also considering changing the name of the inverse function
> from ift to ifft, since it is the inverse of fft, not ft.
> What do you think of this name change? Another possibility is
> fft_inverse.
>
> best
>
> Robert Dodier


Hi!

My 2 euro-cents on naming matter: In general I'm in favour of naming  
functions after what they do, not the underlying numerical algorithm  
that does the calculation. So instead of romberg() or quad_qags() I  
like to see nintegrate() or numeric_integrate() naming. I know Maxima  
currently doesn't officially follow this, but I would be very glad to  
see some progress into this direction.

Mathematica function names are a great example of this - there  
discrete fourier transform is called Fourier[] and InverseFourier[].  
For fourier transform, there are FourierTransform[] and  
InverseFourierTransform[] functions. There are also FourierDCT[] and  
FourierDST[] functions for discrete cosine and sine transforms.

I guess fft, though it's an algorithm name, is in engineer world  
synonimus with discrete fourier transform, but mathematically fft is  
just an algorithm. If we use fft, then also romberg, bisection,  
levenberg and other function names make sense. This naming of  
functions is common in numerical packages such as matlab, scilab,  
octave - where it makes sense. But I think Maxima as a CAS should try  
to avoid this.

FFT is somewhat special, because of it's synonimity with DFT in the  
contex I presented earlier, but still, my propositions for names  
would be:
dft() and inverse_dft() or rather
fourier() and inverse_fourier().
Though fft() and inverse_fft() are not so critical as some other  
names of Maxima functions... but that's just my 2 euro-cents :)

As for the other part - fft working on lists - that's GREAT! Last  
time I was looking at dft in Maxima, and found fft, but it's  
requirement for arrays turned me off. Arrays are very convoluted to  
use in Maxima, never really got round to really using them. Since  
Maxima supports complex numbers it's somewhat backward to have to  
supply 2 arrays (kind of C-like) with real and imaginary parts (I  
know that it's because algorithm is written to operate on two  
arrays :) ). I'm looking forward to fft working on lists.

Regards,
Ziga