On Tue, Jul 20, 2010 at 5:47 PM, David Cournapeau <courn...@gmail.com>wrote:
> On Wed, Jul 21, 2010 at 2:02 AM, David Goldsmith > <d.l.goldsm...@gmail.com> wrote: > > On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith < > d.l.goldsm...@gmail.com> > > wrote: > >> > >> On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud <martin.rasp...@smhi.se > > > >> 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)? DG > > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves)
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion