[Numpy-discussion] numpy.fft, yet again

Charles R Harris charlesr.harris@gmail....
Tue Jul 20 20:54:27 CDT 2010


On Tue, Jul 20, 2010 at 7:28 PM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:

> 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)?
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100720/9f648d8f/attachment.html 


More information about the NumPy-Discussion mailing list