[Numpy-discussion] numpy.fft, yet again
David Goldsmith
d.l.goldsmith@gmail....
Tue Jul 20 20:28:19 CDT 2010
On Tue, Jul 20, 2010 at 5:47 PM, David Cournapeau <cournape@gmail.com>wrote:
> On Wed, Jul 21, 2010 at 2:02 AM, David Goldsmith
> <d.l.goldsmith@gmail.com> wrote:
> > On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith <
> d.l.goldsmith@gmail.com>
> > wrote:
> >>
> >> On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud <martin.raspaud@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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100720/e25f4746/attachment-0001.html
More information about the NumPy-Discussion
mailing list