Fago, Matt - AES wrote:
> I cannot really compute the example without the pad_to support in svn.
> Nevertheless, using something similar (nfft=128, noffset=64) gives similarly
> erroneous results.
>
> Did you add 'pad_to'? If so, thanks!
Good to know. I recently (within the last month) did a bunch of work on
psd, based in a large part on work done by one of my colleagues, Sean
Arms. I was worried some of this had broken existing code, but it
appears more likely that this was already a problem.
After much playing, and reading the Matlab docs, it looks like the
difference is that Matlab normalizes by the sampling frequency. Also,
if a one-sided psd is returned, it multiplies everything by 2. If I
apply these two scaling factors, I get results in line with those
produced by Matlab.
Now, this scaling was not performed by the old code, so this is not a
new incompatibility (bug?) with Matlab. Also, while I have not reviewed
the reference specified in the docstring (Bendat and Piersol 1986), the
book I have handy (Stoica and Moses 2005) does not mention scaling by
the sampling frequency, nor does the included Matlab code perform any
such scaling.
So what should be done here? I would be opposed to making such scaling
the default, as IMHO it tries to do too much and I would have to work
around it to get the more "raw" numbers. However, I am not opposed to
adding (yet another) option to do such scaling.
Other opinions?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-users