On Jun 30, 1:37*pm, Jerry Avins <j...@ieee.org> wrote:
> BobW wrote:
>
....
> > I sense that this technique of packing real data samples into the imaginary
> > part of the input to the FFT is rather uncommon. Is that your take, too?
>
> No. The technique seems to be widely known, but rarely needed.

i think it's rarely needed is because the complex FFTs still do pretty
good. if doing an equally optimized real FFT is only around 1/2 of
the computation of the complex, it hardly often where that extra
octave of computational bandwidth is worth the bother of rolling their
own real FFT (out of 1/2 the size of a complex FFT). unless they do
it for recreational purposes.

the usual reason that, in a real-time frequency-domain process that i
hadn't often bothered with a real FFT is that in the case of
processing real audio signals, you can put two neighboring frames of
this real date and, if you're convolving with a real h[n], you can ge
guaranteed that the output frames of the iFFT you'ld get corresponding
to the two input frames would appear in the real and imaginary parts.
this is because of linearity and time-invariancy of the convolution
operation (by definition) and the fact that Re{j}=0 and Im{1}=0.
there might, because of roundoff error, be numerical sources to some
crosstalk between the two frames, i dunno. you usually don't care
about it (or even think about it) if your data is double float.

> There are
> real-to real FFT libraries available that do the scut work for the user,
> as good libraries should.

Jerry, i wonder if Steven G. Johnson would agree with you here. i
dunno.

r b-j