Is there a sample Java code for fixedpoint FFT?

in article 1138815145.765657.122150@o13g2000cwo.googlegroups.com,
stevenj@alum.mit.edu at stevenj@alum.mit.edu wrote on 02/01/2006 12:32:

> Robert Hay wrote:
>> My problem actually is as follows: My program (in Java) gets two array of
>> integers from another program, uses FFT or Inverse FFT depending on what
>> the calling program requests, and returns two array of integers to the
>> caller. The next time the caller may want to get its original signal by
>> requesting from my program an Inverse FFT operation.
> 
> This is an intrinsic problem -- integers cannot very accurately
> represent the results of a DFT

i don't presume the OP means integral values but fixed-point representation.

> and using an integer FFT will do nothing to solve it.

if there are enough bits in those integers (32+) and if there is some care
taken to scaling - either "block floating-point" or, if that is
computationally too messy, the "unitary" DFT scaling with 1/sqrt(N) so that
there is a divide-by-two (or ASR) ever *other* FFT pass - if you do that,
you can have some decent results.

those LakeDSP guys (the same who either stole Bill Gardner's idea for
zero-delay or low-delay fast convolution or came up with the idea
independently and nearly simultaneously, also a believable POV) had an old
convoluter built out of several Mot DSP56002, fixed-point DSPs, and i think
it sounded pretty good.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

r b-j wrote:
> i don't presume the OP means integral values but fixed-point representation.

A distinction without a difference; fixed-point vs. integers is just a
choice of scale factors.

> if there are enough bits in those integers (32+) and if there is some care
> taken to scaling [...] you can have some decent results.

The errors in a fixed-point FFT, which go as sqrt(N), are intrinsically
worse than the errors in a floating-point FFT, which go as sqrt(log N)
on average.  Because of that, the OP is almost certainly better off
using a floating-point FFT and converting to integers at the end with
an appropriate scaling.  Besides which floating-point FFTs are simpler
to implement than fixed-point, and are probably faster as well on a
modern general-purpose CPU.  (We're not talking about DSP chips here,
or embedded systems without an FPU.)

Steven