matplotlib-users Mailing List for matplotlib (Page 16)

>
> The next inquiry is related to xticks.
> I have added
>
> xticks(linspace(0,2*pi,24,endpoint=False))
>
> The difference between consecutive xticks is varying between 14 and 16
> degrees.
The following works around the roundoff for me:
xticks(linspace(0, 360, 24, endpoint=False) * pi/180.)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Dec 2, 2008 at 11:27 AM, Nils Wagner
<nw...@ia...>wrote:
> Thank you very much !
> It would be nice to have that information in the docstring
>
Done.
> The next inquiry is related to xticks.
> I have added
>
> xticks(linspace(0,2*pi,24,endpoint=False))
>
> The difference between consecutive xticks is varying between 14 and 16
> degrees.
>
> For what reason ?
Looks like roundoff error. For instance:
linspace(0, 2*pi, 24)[7] * 180. / pi
104.999999999999
If you format that with '%d', it becomes 104, not 105.
Is there an accepted way of doing this rounding in matplotlib that doesn't
round in odd cases?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

running the last ipython version now (0.9.1), and it does not help (got stuck
the same way).
The difference now is that ipython provides a message:
Warning: Timeout for mainloop thread exceeded
switching to nonthreaded mode (until mainloop wakes up again)
It seems that ipython developers did catch the issue and made this message to be
delivered so that at least you can go on working with your session. However, I
cannot do anything with matplotlib after that message is given, and I have to
get out of the session and start again if I want to plot something...
This seems therefore linked to matplotlib and not ipython.. Just that now
ipython does not get stuck anymore but provide a message regarding the thread
issue. (Not very useful in this context for me unfortunately)
See the ipython scipy thread in fact :
http://lists.ipython.scipy.org/pipermail/ipython-user/2008-July/005628.html
So as far as I can tell this is a matplotlib bug and noone so far encountering
this problem has a really good idea why it occurs. Indeed the problem occurs
*only* when I launch matplotlib commands (after some time in my ipython session).
Really annoying but as mentioned before, I cannot get a set of commands which
consistenly break the session, so...
Eric
Yannick Copin wrote:
> I would say the pb is actually coming from ipython. I experienced it
> while using ipython-0.8.1, but I guess it disappeared starting with
> ipython-0.8.3 (see http://ipython.scipy.org/moin/WhatsNew083:
> "Multithreaded shells (used e.g. by matplotlib interaction) have been
> improved, reducing the possibility of corner case deadlocks."). I'm now
> using 0.8.4 and I don't remember I ever had this pb again.

On 2008年12月02日 12:43:14 -0500 Michael Droettboom <md...@st...>
wrote:
> Yeah. This is a known bug that was fixed since 0.98.1.
> 
Rats! Lets hope the Fedora guys are quick with the updating.
Thanks for ending my head-banging, though.
/W

On Tue, 2 Dec 2008 11:11:44 -0600 "Ryan May" <rm...@gm...> wrote:
> On Tue, Dec 2, 2008 at 10:12 AM, Wildemar Wildenburger <
> wil...@fr...> wrote:
> 
> > (snip)
> > polar([1,2,3,4],[1,3,4,2], "o")
> >
> > to my surprise does not give me 4 distinct points but rather some
> > interpolated points as well. This is highly unexpected, nay,
> > unwanted. It used to work well in Fedora 8 (don't know which
> > version I ran there).
> >
> > Fedora 10
> > Python 2.5.2
> > matplotlib 0.98.1
> >(snip)
> 
> Works for me on 0.98.3 and SVN HEAD. I get 4 blue dots. Can you
> send an image showing the output you're getting?
> 
See the attached screenshot.
thanks,
/W

Yeah. This is a known bug that was fixed since 0.98.1.
Cheers,
Mike
Ryan May wrote:
> On Tue, Dec 2, 2008 at 10:12 AM, Wildemar Wildenburger 
> <wil...@fr... <mailto:wil...@fr...>> wrote:
>
> Hi there,
>
> telling pyplot
>
> polar([1,2,3,4],[1,3,4,2], "o")
>
> to my surprise does not give me 4 distinct points but rather some
> interpolated points as well. This is highly unexpected, nay, unwanted.
> It used to work well in Fedora 8 (don't know which version I ran
> there).
>
> Fedora 10
> Python 2.5.2
> matplotlib 0.98.1
>
> Any ideas?
>
>
> Works for me on 0.98.3 and SVN HEAD. I get 4 blue dots. Can you send 
> an image showing the output you're getting?
>
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, 2 Dec 2008 11:14:48 -0600
 "Ryan May" <rm...@gm...> wrote:
> On Tue, Dec 2, 2008 at 11:07 AM, Nils Wagner
> <nw...@ia...>wrote:
> 
>> Hi all,
>>
>> If I run the attached example I obtain no polar plots, 
>>but a view like
>> plot(t,r_1) - for what reason ?
>>
> 
> You need to specify polar=True to the subplot commands. 
>Try this:
> 
> from pylab import subplot, polar, linspace, show
> from numpy import pi, sin, cos
> t = linspace(0,2*pi,20)
> r_1 = (1+sin(t))
> r_2 = (1+cos(t))
> subplot(211, polar=True)
> polar(t,r_1) #Or can use plot()
> subplot(212, polar=True)
> polar(t,r_2)
> show()
> 
> Ryan
> 
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
 
Hi Ryan,
Thank you very much !
It would be nice to have that information in the docstring
subplot(*args, **kwargs)
 Create a subplot command, creating axes with::
 subplot(numRows, numCols, plotNum)
 where *plotNum* = 1 is the first plot number and 
increasing *plotNums*
 fill rows first. max(*plotNum*) == *numRows* * 
*numCols*
The next inquiry is related to xticks.
I have added
xticks(linspace(0,2*pi,24,endpoint=False))
The difference between consecutive xticks is varying 
between 14 and 16 degrees.
For what reason ?
Nils

On Tue, Dec 2, 2008 at 11:07 AM, Nils Wagner
<nw...@ia...>wrote:
> Hi all,
>
> If I run the attached example I obtain no polar plots, but a view like
> plot(t,r_1) - for what reason ?
>
You need to specify polar=True to the subplot commands. Try this:
from pylab import subplot, polar, linspace, show
from numpy import pi, sin, cos
t = linspace(0,2*pi,20)
r_1 = (1+sin(t))
r_2 = (1+cos(t))
subplot(211, polar=True)
polar(t,r_1) #Or can use plot()
subplot(212, polar=True)
polar(t,r_2)
show()
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Dec 2, 2008 at 10:12 AM, Wildemar Wildenburger <
wil...@fr...> wrote:
> Hi there,
>
> telling pyplot
>
> polar([1,2,3,4],[1,3,4,2], "o")
>
> to my surprise does not give me 4 distinct points but rather some
> interpolated points as well. This is highly unexpected, nay, unwanted.
> It used to work well in Fedora 8 (don't know which version I ran
> there).
>
> Fedora 10
> Python 2.5.2
> matplotlib 0.98.1
>
> Any ideas?
>
Works for me on 0.98.3 and SVN HEAD. I get 4 blue dots. Can you send an
image showing the output you're getting?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi all,
 
If I run the attached example I obtain no polar plots, but 
a view like plot(t,r_1) - for what reason ?
Nils
python -i test_subplot_polar.py --verbose-helpful
$HOME=/home/nwagner
CONFIGDIR=/home/nwagner/.matplotlib
/usr/lib/python2.4/site-packages/matplotlib/__init__.py:662: 
UserWarning: Bad val "inputenc" on line #144
 "text.latex.unicode : inputenc # use "ucs" and 
"inputenc" LaTeX packages for handling
"
 in file "/home/nwagner/.matplotlib/matplotlibrc"
 Could not convert "inputenc" to boolean
 warnings.warn('Bad val "%s" on line #%d\n\t"%s"\n\tin 
file \
matplotlib data path 
/usr/lib/python2.4/site-packages/matplotlib/mpl-data
loaded rc file /home/nwagner/.matplotlib/matplotlibrc
matplotlib version 0.98.3
verbose.level helpful
interactive is False
units is False
platform is linux2
Using fontManager instance from 
/home/nwagner/.matplotlib/fontList.cache
backend GTKAgg version 2.5.3
findfont: Matching 
:family=sans-serif:style=normal:variant=normal:weight=normal:stretch=normal:size=medium 
to Bitstream Vera Sans 
(/usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/Vera.ttf) 
with score of 1.000000
Found dvipng version 1.5

Hi there,
telling pyplot
 polar([1,2,3,4],[1,3,4,2], "o")
to my surprise does not give me 4 distinct points but rather some
interpolated points as well. This is highly unexpected, nay, unwanted.
It used to work well in Fedora 8 (don't know which version I ran
there).
Fedora 10
Python 2.5.2
matplotlib 0.98.1
Any ideas?
/W

All right, 
as information for all :
reinstalling cygwin from scratch, reinstalling python from scratch, and finaly matplotlib now works...
Cheers,
Thomas
**********************
Thomas Lecocq
Geologist
Ph.D.Student (Seismology)
Royal Observatory of Belgium
**********************
From: thl...@ms...
To: mat...@li...
Date: Tue, 2 Dec 2008 12:50:24 +0000
Subject: [Matplotlib-users] Cygwin1.dll error import pyplot
Hi all,
I've searched the mailing archive, and I can't find an anwser to my problem :
i'm running Python2.5 on a WinXP32 box. I just reinstalled cygwin to exclude a version-problem. Matplotlib version is 0.98.3 (got from easy_install matplotlib command)
i'm just trying this :
from matplotlib.pyplot import *
and the answer is :
 3 [main] ? (2808) C:\Python25\pythonw.exe: *** fatal error - Incompatible cygwin .dll -- incompatible per_process info 0 != 168
booooom...
I really don't know how to solve this...
Thanks a lot in advance for your help !
Thomas
**********************
Thomas Lecocq
Geologist
Ph.D.Student (Seismology)
Royal Observatory of Belgium
**********************

There is an explicit offset of one pixel on the left when it sets up a 
clip box in Agg. I don't know why this is there, but it dates back to 
0.98.0, and earlier versions did something completely different. I can 
only guess it was to compensate for an earlier bug in the precise 
drawing of the axes rectangle. I can't explain why it would have 
different behavior on Windows vs. Linux, though.
I have fixed this in SVN r6465 and am including a patch below (which 
unfortunately requires a recompile).
Cheers,
Mike
Modified: trunk/matplotlib/src/_backend_agg.cpp
===================================================================
--- trunk/matplotlib/src/_backend_agg.cpp	2008年12月01日 19:35:39 UTC (rev 6465)
+++ trunk/matplotlib/src/_backend_agg.cpp	2008年12月02日 15:27:23 UTC (rev 6466)
@@ -312,8 +312,8 @@
 
 double l, b, r, t;
 if (py_convert_bbox(cliprect.ptr(), l, b, r, t)) {
- rasterizer.clip_box(int(mpl_round(l)) + 1, height - int(mpl_round(b)),
- int(mpl_round(r)), height - int(mpl_round(t)));
+ rasterizer.clip_box(int(mpl_round(l)), height - int(mpl_round(b)),
+ int(mpl_round(r)), height - int(mpl_round(t)));
 }
 
 _VERBOSE("RendererAgg::set_clipbox done");

Hi all,
I've searched the mailing archive, and I can't find an anwser to my problem :
i'm running Python2.5 on a WinXP32 box. I just reinstalled cygwin to exclude a version-problem. Matplotlib version is 0.98.3 (got from easy_install matplotlib command)
i'm just trying this :
from matplotlib.pyplot import *
and the answer is :
 3 [main] ? (2808) C:\Python25\pythonw.exe: *** fatal error - Incompatible cygwin .dll -- incompatible per_process info 0 != 168
booooom...
I really don't know how to solve this...
Thanks a lot in advance for your help !
Thomas
**********************
Thomas Lecocq
Geologist
Ph.D.Student (Seismology)
Royal Observatory of Belgium
**********************

Thanks for verifying this Sünnje. It looks like an Agg bug. I just tried 
changing to the GTK backend in Linux and the problem disappears.
Gary
Sunnje L Basedow wrote:
> Hi Gary,
> I just tested your example, also on Intrepid with 0.98.3, and I get the
> exact same behaviour as you, with white pixels in the left column. But I
> have no idea why, sorry.
> Sünnje

Hi Gary,
I just tested your example, also on Intrepid with 0.98.3, and I get the
exact same behaviour as you, with white pixels in the left column. But I
have no idea why, sorry.
Sünnje
-----Original Message-----
From: Gary Ruben [mailto:gr...@bi...]
Sent: Tue 12/2/2008 11:13
To: mat...@li...
Subject: [Matplotlib-users] different behaviour in Windows and Linux
 
I'm wondering whether someone can reproduce the following problem I'm 
seeing in Ubuntu Intrepid.
I often use matplotlib to save images created with imshow to take 
advantage of matplotlib's colour maps. I've noticed that the behaviour 
is different for 0.98.3 between Windows XP-32 and Ubuntu Intrepid. I 
don't remember seeing this problem with earlier versions. This minimal 
example demonstrates the problem:
--
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.cm as cm
px = 3
rcFig = {'figsize': (1, 1),
 'dpi': px,
 'subplot.bottom': 0,
 'subplot.left': 0,
 'subplot.right': 1,
 'subplot.top': 1,
 }
plt.rc('figure', **rcFig)
a = np.ones((px, px))
plt.axis('off')
plt.imshow(a, cmap=cm.gray)
plt.savefig('mpl_out.png', dpi=px)
--
In Windows I get the correct behaviour - in this case a 3x3 image with 
all black pixels:
bbb
bbb
bbb
However, in Linux the leftmost column of pixels is white
wbb
wbb
wbb
By the way, I think an imsave function that just saved an array as an 
image with a specified colourmap and clims would be a nice addition to 
matplotlib.image. Is there another way to achieve the same 1-to-1 array 
element-to-pixel image saving applying colourmaps and clims?
thanks,
Gary R.
-------------------------------------------------------------------------
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
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I just realised that the example I gave may not be the best since it's 
not obvious what the autoscaling will do when all array values are 
equal. Nevertheless, even when the array contains a range of values and 
I use a greyscale colourmap, I'm seeing the leftmost pixel column set to 
all white when the array values in that column are all zeros and the 
image is written in Linux, whereas it's black when written in Windows.
Gary

I am indeed using ipython 0.8.1. Will try to upgrade and see how it goes.
Indeed this looks like the deadlocks people mentioned, within, as Xavier
emphasised, no way to CTRL-C it to kill it.
thanks for the tips
Eric
Yannick Copin wrote:
> Salut Eric,
> 
>> Date: 2008年12月01日 20:08:00 +0100
>> From: Eric Emsellem <ems...@ob...>
>> Subject: [Matplotlib-users] pylab or not... crashes or not
>>
>> - when I start a session with "ipython -pylab" I often get crashes
>> with my
>> session. When I mean "often", it means really often like once
>> everything 1/2h or
>> so. A crash means that the command I just sent gets stuck and the only
>> way for
>> me to get it back is to kill the PID of the ipython process...
> [...]
>> IPython 0.8.1 -- An enhanced Interactive Python.
> 
> I would say the pb is actually coming from ipython. I experienced it
> while using ipython-0.8.1, but I guess it disappeared starting with
> ipython-0.8.3 (see http://ipython.scipy.org/moin/WhatsNew083:
> "Multithreaded shells (used e.g. by matplotlib interaction) have been
> improved, reducing the possibility of corner case deadlocks."). I'm now
> using 0.8.4 and I don't remember I ever had this pb again.
> 
> See you! (and congrats ;-) )

I'm wondering whether someone can reproduce the following problem I'm 
seeing in Ubuntu Intrepid.
I often use matplotlib to save images created with imshow to take 
advantage of matplotlib's colour maps. I've noticed that the behaviour 
is different for 0.98.3 between Windows XP-32 and Ubuntu Intrepid. I 
don't remember seeing this problem with earlier versions. This minimal 
example demonstrates the problem:
--
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.cm as cm
px = 3
rcFig = {'figsize': (1, 1),
 'dpi': px,
 'subplot.bottom': 0,
 'subplot.left': 0,
 'subplot.right': 1,
 'subplot.top': 1,
 }
plt.rc('figure', **rcFig)
a = np.ones((px, px))
plt.axis('off')
plt.imshow(a, cmap=cm.gray)
plt.savefig('mpl_out.png', dpi=px)
--
In Windows I get the correct behaviour - in this case a 3x3 image with 
all black pixels:
bbb
bbb
bbb
However, in Linux the leftmost column of pixels is white
wbb
wbb
wbb
By the way, I think an imsave function that just saved an array as an 
image with a specified colourmap and clims would be a nice addition to 
matplotlib.image. Is there another way to achieve the same 1-to-1 array 
element-to-pixel image saving applying colourmaps and clims?
thanks,
Gary R.

On Tue, Dec 2, 2008 at 7:44 AM, Nils Wagner
<nw...@ia...> wrote:
>>>
>>> Hi all,
>>>
>>> I would like to visualize the ovality of a perturbed
>>> circular path by a polar plot.
>>> How can I improve the view wrt to scaling and ticks ?
>>
>> ylim(0, 2)
>> yticks(arange(0, 2, 0.25))
> Thank you for your reply.
>
> It is on the right path.
>
> Is it possible to restrict the view to an annulus
> 0.75 < r < 1.25 ?
>
Sorry, I'm not sure about that. I've cc'd the list incase anyone else can help.
Cheers,
Matt
-- 
Matt Foster | http://hackerific.net

On 12/1/2008 7:27 PM Mike Hearne apparently wrote:
 > The long answer is: I have a map with a varying background. I'd like to be able to create a white drop-shadow 
behind darker text, so that the text can stand out reasonably clearly against most colored backgrounds.
OK. I can imagine this. If I wanted a quick pass at
a cheap substitute for that kind of effect in PostScript, I'd
probably stroke the text outline in white and then fill
in the dark color. Do not know if that is possible in mpl or
desirable for you.
 > The short answer is that my customers want it.
Reason enough.
Thanks,
Alan

The long answer is: I have a map with a varying background. I'd like to 
be able to create a white drop-shadow behind darker text, so that the text 
can stand out reasonably clearly against most colored backgrounds.
The short answer is that my customers want it.
--Mike
Alan G Isaac <ai...@am...> 
12/01/08 02:25 PM
To
mat...@li...
cc
Subject
Re: [Matplotlib-users] plot with drop shadow
Mike Hearne wrote:
 > Along similar lines, has anyone figured out a way to have a drop shadow 
effect for text on a plot?
Out of curiosity, what is the payoff
(in communication or aesthetics)
of such a thing?
Thanks,
Alan Isaac
-------------------------------------------------------------------------
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
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

> From: Ryan May [mailto:rm...@gm...]
> Fago, Matt - AES wrote:
> > I suppose the issue is: what is correct? Or is it a matter of
> definition?
[...]
> Yeah, scaling by a factor of two for one-sided is definitely correct now
> that I think about it. Note, however, that the scaling by the length is
> not the problem. In fact, the current psd implementation does this
> correctly when it corrects for the power in the window. The problem
> stems from matlab scaling by the sampling frequency. Stoica and Moses
> don't do this, nor does Welch 1967. I'm all for doing things in a
> Matlab-compatible way--when they're correct. One of the reasons I
> stopped using Matlab was that it tried to be too smart for me.
Yes, multiplying by 2/fs does look fairly good. Perhaps this comes about due to the Matlab implementation of the FFT?
> > Note that the Matplotlib results also seem to have significantly less
> > frequency resolution than
> > the Matlab results. Is this the case, or am I not using noffset, nfft,
> > and pad_to correctly?
>
> It's not that you're using those incorrectly, but rather that you failed
> to notice that the default window is the Hanning window, not
> rectangular. Try adding window=mlab.window_none to the call. (Sorry, I
> meant to mention that before in my reply.
Ah ... many thanks. Silly me.
 - Matt
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

Dear Ryan,
Thank your very much for your kind reply. I had already a couple of
solutions to that problem, and your adds nicely to them!
I am very grateful to everyone who have been so helpful and can assure
you will also be formally acknowledged at the conclusion of this
project.
With warmest regards,
2008年12月1日 Ryan May <rm...@gm...>:
> Mauro Cavalcanti wrote:
>>
>> Dear ALL,
>>
>> Is there any example of toggling points on and off a MPL Basemap? I
>> see that there matplotlib artists have a handy "set_visible()" method,
>> but if I have a map with plotted points and use
>> "ax.set_visible(False)", the entire map is made invisible!
>
> Sorry this took so long, I lost you in my queue.
>
> You need to first save the results of the command you use to plot the points
> (every plotting command returns an object or set of objects that represent
> what was added to the plot.). You then call set_visible() on this object.
> Your problem was that calling ax.set_visible(False) made the entire Axes
> object invisible, which, as you saw, hid the plot. Here's a modified version
> of the plotcities example:
>
>
> from mpl_toolkits.basemap import Basemap as Basemap
>
> m = Basemap()
> x, y = [70,30,110,-97,75,-10], [35, 40, 45, 60, -10, -40]
> x,y = m(x,y)
> m.drawcoastlines()
> m.fillcontinents()
> pts = m.scatter(x,y,25,marker='o',edgecolors='none',zorder=10)
> pts.set_visible(False) #Uncomment to make visible
> plt.show()
>
> Hope this helps,
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>
-- 
Dr. Mauro J. Cavalcanti
Ecoinformatics Studio
P.O. Box 46521, CEP 20551-970
Rio de Janeiro, RJ, BRASIL
E-mail: mau...@gm...
Web: http://studio.infobio.net
Linux Registered User #473524 * Ubuntu User #22717
"Life is complex. It consists of real and imaginary parts."

Fago, Matt - AES wrote:
> I suppose the issue is: what is correct? Or is it a matter of definition?
> 
> I don't have Stoica and Moses, but Bendat and Piersol eqn 11.102:
> 
> One_Sided_PSD = 2/(n_d * N * dt) * Sum(FFT^2)
> 
> where there are n_d is the number of averages and N is the number of points in the FFT.
> That seems to be scaling by the length? I'm fairly certain that the factor of two (as shown
> above) is required for a one-sided PSD, as that comes from 'removing' the negative
> frequency range.
> 
> Note that Matlab shows such scaling (by 2/L) even when computing the power spectra directly
> from a raw (unaveraged) FFT:
> 
> http://www.mathworks.com/support/tech-notes/1700/1702.html
>
> To me, as Matplotlib is striving to be Matlab-compatible, the default behaviour should be to
> give results as close to the Matlab implementation as possible. One could always have an
> option to turn off the scaling.
Yeah, scaling by a factor of two for one-sided is definitely correct now 
that I think about it. Note, however, that the scaling by the length is 
not the problem. In fact, the current psd implementation does this 
correctly when it corrects for the power in the window. The problem 
stems from matlab scaling by the sampling frequency. Stoica and Moses 
don't do this, nor does Welch 1967. I'm all for doing things in a 
Matlab-compatible way--when they're correct. One of the reasons I 
stopped using Matlab was that it tried to be too smart for me.
> Note that the Matplotlib results also seem to have significantly less frequency resolution than
> the Matlab results. Is this the case, or am I not using noffset, nfft, and pad_to correctly?
It's not that you're using those incorrectly, but rather that you failed 
to notice that the default window is the Hanning window, not 
rectangular. Try adding window=mlab.window_none to the call. (Sorry, I 
meant to mention that before in my reply.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma