On Tue, Jul 20, 2010 at 6:02 PM, 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 GPL package so we don't use it. The fftw homepage is
here<http://www.fftw.org/>
.

Chuck
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to