On Tue, Jul 20, 2010 at 7:28 PM, David Goldsmith <[email protected]>wrote:
> On Tue, Jul 20, 2010 at 5:47 PM, David Cournapeau <[email protected]>wrote: > >> On Wed, Jul 21, 2010 at 2:02 AM, David Goldsmith >> <[email protected]> wrote: >> > On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith < >> [email protected]> >> > wrote: >> >> >> >> On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud < >> [email protected]> >> >> wrote: >> >>> >> >>> -----BEGIN PGP SIGNED MESSAGE----- >> >>> Hash: SHA1 >> >>> >> >>> David Goldsmith skrev: >> >>> > >> >>> > >> >>> > Interesting comment: it made me run down the fftpack tutorial >> >>> > < >> http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/> >> >>> > josef has alluded to in the past to see if the suggested pointer >> >>> > could point there without having to write a lot of new content. >> >>> > What I found was that although the scipy basic fft functions >> don't >> >>> > support it (presumably because they're basically just wrappers >> for >> >>> > the numpy fft functions), scipy's discrete cosine transforms >> >>> > support >> >>> > an "norm=ortho" keyword argument/value pair that enables the >> >>> > function to return the unitary versions that you describe above. >> >>> > There isn't much narrative explanation of the issue yet, but it >> got >> >>> > me wondering: why don't the fft functions support this? If >> there >> >>> > isn't a "good" reason, I'll go ahead and submit an enhancement >> >>> > ticket. >> >>> > >> >>> > >> >>> > Having seen no post of a "good reason," I'm going to go ahead and >> file >> >>> > enhancement tickets. >> >>> >> >>> Hi, >> >>> >> >>> I have worked on fourier transforms and I think normalization is >> >>> generally seen >> >>> as a whole : fft + ifft should be the identity function, thus the >> >>> necessity of a >> >>> normalization, which often done on the ifft. >> >>> >> >>> As one of the previous poster mentioned, sqrt(len(x)) is often seen as >> a >> >>> good >> >>> compromise to split the normalization equally between fft and ifft. >> >>> >> >>> In the sound community though, the whole normalization often done >> after >> >>> the fft, >> >>> such that looking at the amplitude spectrum gives the correct >> amplitude >> >>> values >> >>> for the different components of the sound (sinusoids). >> >>> >> >>> My guess is that normalization requirements are different for every >> user: >> >>> that's >> >>> why I like the no normalization approach of fftw, such that anyone >> does >> >>> whatever >> >>> he/she/it wants. >> >> >> >> I get the picture: in the docstring, refer people to fftw. >> >> >> >> DG >> > >> > I can't find this fftw function in either numpy or scipy - where is it? >> >> It is a library for fft - the OP was referring to its conventions for >> normalization (i.e. no normalization) >> > > That would have been helpful to have stated at the outset. > > So, what does all this amount to vis-a-vis the ticket I created suggesting > that fft/ifft be enhanced w/ a norm keyword parameter? "Won't fix"? And > what/why should anything be said about normalization if our functions only > return one kind of normalization and that normalization is already > well-documented (it is explicit in the provided definitions we use for the > two transforms)? > I for one would welcome no normalization, or at least user normalization since undoing the damage of the current normalization is work. How about a scale keyword? scale=None -- current behaviour, default. scale=some_number -- multiply the result by some_number. Can simplify when equal to 1. Chuck
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
