robert bristow-johnson wrote:
> 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.

I've been hoping he would weigh in.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯