Hello Tito and Chris, Thanks also for your explanations. Sorry I didn't see them before I responded earlier.
I am surprised at the variety of approaches to scaling. It looks like not doing any scaling is an important option. In the latest unreleased code, callers could pass in 1.0 as scale factors. But then I am still doing an unnecessary multiply by 1.0. So I think I will provide an "unscaled" option for speed. Phil On Thu, Nov 5, 2015 at 6:07 AM, Chris Cannam <can...@all-day-breakfast.com> wrote: > > On Wed, Nov 4, 2015, at 04:56 PM, Phil Burk wrote: > > Is there a "right" way or a "wrong" way or is there just "my" way? > > I think in the context of a library there are two questions here -- what > scaling should an FFT implementation use (behind the scenes in the > functions it provides), and what scaling is appropriate for a particular > application that makes use of an FFT implementation. > > Without getting into the second question, most libraries I've used > either scale by 1 in both directions (FFTW, KissFFT) or scale the > forward transform by 1 and the inverse by 1/M (MATLAB, NumPy). > > The exceptions that come to mind are: > > * Apple's Accelerate framework scales the complex-complex forward > transform by 1, but the real-complex forward transform by 2 (that's 2, > not 2/M). In both cases it scales the inverse by 1/M > > * Fixed-point implementations, e.g. OpenMAX, which has you specify the > scale factor when you call the function > > My preference is for scaling by 1 in both directions and leaving it up > to the caller. > > > Chris > _______________________________________________ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp >
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
