> I hope fft()/ifft() are at least specified correctly, if not
> implemented correctly in saolc. This is a potentially very
> useful way of doing things, but I had a really hard time getting
> the semantics right.
>
> John, is this your interpretation of the fft() spec also?
Yes, the:
> The first 256 points are DC to the Nyquist [0:pi], and the second
> 256 points (for a size 512 DFT) are the reflection from Nyquist
> to twice Nyquist [pi:2*pi].
Is my understanding. I'm actually planning to revisit the fft/ifft
code soon for optimization, as I recall, if there were any open
issues with regards to the fft/ifft spec, it was concerning whether
all the uses of "len" in the equations in the spec defining the
fft() and ifft() were really meant to be "len", or if some of them
were meant to be "size" instead (to clarify for list members, the
fft and ifft opcode supports sliding window analysis, so the
user may supply the actual (power-of-two) size of the FFT "size",
the "len" of the "frame" to do sliding computation over, and the
"shift" of sliding to do, with rules if a subset of "len", "size",
and "shift" are specified). I honestly can't remember if we closed
this issue or not, when I get to the fft/ifft optimization code in
a few weeks I'll report back ...
Incidently, the "power-of-two" restriction for size (along with the
8192 max) for fft/ifft will really mesh well with sfront's approach
to optimization (generating custom code for each opcode invocation,
based on all static knowledge), so I'd be in favor of keeping it.
--jl
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:49 EDT