Richard Fateman wrote:
> my suspicion is that the time to actually do the arithmetic will be
> dominated by the overhead associated with each arithmetic operation.
> With some profiling, we could tell.
What overhead are you talking about here? Both cmucl and sbcl support
unboxed (complex double-float) arithmetic. For other Lisps that don't
have unboxed complex arithmetic, I can see the overhead being the
dominant factor, especially boxing up the result.
>
> Also, shouldn't the fft work with bigfloats, etc.?
The current code does not handle bigfloats, I think, but a bigfloat fft
would be useful.
Ray