You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(3) 
_{Jun}

_{Jul}

_{Aug}
(12) 
_{Sep}
(12) 
_{Oct}
(56) 
_{Nov}
(65) 
_{Dec}
(37) 

2004 
_{Jan}
(59) 
_{Feb}
(78) 
_{Mar}
(153) 
_{Apr}
(205) 
_{May}
(184) 
_{Jun}
(123) 
_{Jul}
(171) 
_{Aug}
(156) 
_{Sep}
(190) 
_{Oct}
(120) 
_{Nov}
(154) 
_{Dec}
(223) 
2005 
_{Jan}
(184) 
_{Feb}
(267) 
_{Mar}
(214) 
_{Apr}
(286) 
_{May}
(320) 
_{Jun}
(299) 
_{Jul}
(348) 
_{Aug}
(283) 
_{Sep}
(355) 
_{Oct}
(293) 
_{Nov}
(232) 
_{Dec}
(203) 
2006 
_{Jan}
(352) 
_{Feb}
(358) 
_{Mar}
(403) 
_{Apr}
(313) 
_{May}
(165) 
_{Jun}
(281) 
_{Jul}
(316) 
_{Aug}
(228) 
_{Sep}
(279) 
_{Oct}
(243) 
_{Nov}
(315) 
_{Dec}
(345) 
2007 
_{Jan}
(260) 
_{Feb}
(323) 
_{Mar}
(340) 
_{Apr}
(319) 
_{May}
(290) 
_{Jun}
(296) 
_{Jul}
(221) 
_{Aug}
(292) 
_{Sep}
(242) 
_{Oct}
(248) 
_{Nov}
(242) 
_{Dec}
(332) 
2008 
_{Jan}
(312) 
_{Feb}
(359) 
_{Mar}
(454) 
_{Apr}
(287) 
_{May}
(340) 
_{Jun}
(450) 
_{Jul}
(403) 
_{Aug}
(324) 
_{Sep}
(349) 
_{Oct}
(385) 
_{Nov}
(363) 
_{Dec}
(437) 
2009 
_{Jan}
(500) 
_{Feb}
(301) 
_{Mar}
(409) 
_{Apr}
(486) 
_{May}
(545) 
_{Jun}
(391) 
_{Jul}
(518) 
_{Aug}
(497) 
_{Sep}
(492) 
_{Oct}
(429) 
_{Nov}
(357) 
_{Dec}
(310) 
2010 
_{Jan}
(371) 
_{Feb}
(657) 
_{Mar}
(519) 
_{Apr}
(432) 
_{May}
(312) 
_{Jun}
(416) 
_{Jul}
(477) 
_{Aug}
(386) 
_{Sep}
(419) 
_{Oct}
(435) 
_{Nov}
(320) 
_{Dec}
(202) 
2011 
_{Jan}
(321) 
_{Feb}
(413) 
_{Mar}
(299) 
_{Apr}
(215) 
_{May}
(284) 
_{Jun}
(203) 
_{Jul}
(207) 
_{Aug}
(314) 
_{Sep}
(321) 
_{Oct}
(259) 
_{Nov}
(347) 
_{Dec}
(209) 
2012 
_{Jan}
(322) 
_{Feb}
(414) 
_{Mar}
(377) 
_{Apr}
(179) 
_{May}
(173) 
_{Jun}
(234) 
_{Jul}
(151) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(35) 
2
(29) 
3
(12) 
4

5
(8) 
6
(5) 
7
(3) 
8
(38) 
9
(15) 
10
(20) 
11
(14) 
12
(12) 
13
(17) 
14
(6) 
15
(41) 
16
(38) 
17
(31) 
18
(7) 
19
(14) 
20
(12) 
21
(3) 
22
(3) 
23
(15) 
24
(4) 
25

26
(3) 
27
(2) 
28
(7) 
29
(16) 
30
(17) 
31
(10) 



From: Fago, Matt  AES <Matt.Fago@it...>  20081201 22:50:55

> From: Ryan May [mailto:rmay31@...] > 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 onesided 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 > Matlabcompatible waywhen 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 email 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 email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this email and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this email. 
From: Mauro Cavalcanti <maurobio@gm...>  20081201 22:48:20

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 <rmay31@...>: > 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 20551970 Rio de Janeiro, RJ, BRASIL Email: maurobio@... Web: http://studio.infobio.net Linux Registered User #473524 * Ubuntu User #22717 "Life is complex. It consists of real and imaginary parts." 
From: Ryan May <rmay31@gm...>  20081201 22:31:59

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 onesided 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/technotes/1700/1702.html > > To me, as Matplotlib is striving to be Matlabcompatible, 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 onesided 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 Matlabcompatible waywhen 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 
From: Xavier Gnata <xavier.gnata@gm...>  20081201 22:19:08

John Hunter wrote: > On Mon, Dec 1, 2008 at 1:08 PM, Eric Emsellem > <emsellem@...> wrote: >> Hi >> >> this may be a known problem (didn't find anything on this issue) but here it is: >> >>  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... >> >> The problem is that it is almost impossible to reproduce a systematic behaviour >> there so I cannot really send you a list of commands which results in a crash. >> It just happens (often). However, after someone suggested it, I now enter >> Ipython by a simple "ipython" and do immediately "from pylab import *". And then >> I have NO crashes whatsoever. >> >> any suggestion there? Is that normal? > > It is definitely not normal  it almost never happens to me. Does it > help if you run TkAgg instead of GTKAgg. Are you importing/using > anything else when this is happening? What version of numpy are you > running? Well I never use ipython pylab and always use tkagg. It could be a race in the way ipython manage to do that: http://ipython.scipy.org/moin/Cookbook/InterruptingThreads What version of ipython are you using? Xavier 
From: Fago, Matt  AES <Matt.Fago@it...>  20081201 22:08:00

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 onesided 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/technotes/1700/1702.html To me, as Matplotlib is striving to be Matlabcompatible, 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. 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? Thanks for your help, Matt ________________________________________ From: Ryan May [rmay31@...] Sent: Monday, December 01, 2008 1:58 PM To: Fago, Matt  AES Cc: Matplotlib Users Subject: Re: [Matplotlibusers] Matplotlib PSD bug? 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 onesided 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 email 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 email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this email and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this email. 
From: John Hunter <jdh2358@gm...>  20081201 21:53:35

On Mon, Dec 1, 2008 at 3:40 PM, Andrew Straw <strawman@...> wrote: > I appreciate the work you're doing on this, and while I don't have any > very strong opinions on the API questions you raise, I would request > that you include in the docstrings information at least at the level of > the above, listing the scaling issue, the sources you've followed and > how and why you've chosen to follow them or deviate, and differences > with the default behavior of other software. I recently helped a > colleague use Matlab's PSD/pwelch functions and had to spend some time > sending in sine waves of various frequencies and amplitudes to figure > out what the results meant. If matplotlib gives different results by > default, I think it should 1) justify why and 2) indicate what option(s) > may be set to get results equivalent to other systems, including Matlab. My preference is to strive for matlab compatability here. I am pretty sure it was compatible with matlab in my original tests to several significant digits, but I no longer have the test code and my memory is fuzzy because it was over 5 years ago. But I intended this function to be matlab compatible, and if it is not I would prefer to see it compatible even if it means breaking some existing code. It is possible that the original code did not scale with sampling frequency and was compatible, but over time we've made enhancements that broke compatibility. Its been a long time since I used and tested against matlab. If there is good reason to add support for an alternate scaling, we can easily support it with kwargs. But since the signature and origins of this function were matlab compatibility, I think it is least confusing if the default output has similar scaling. JDH 
From: Ryan May <rmay31@gm...>  20081201 21:44:33

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 
From: Andrew Straw <strawman@as...>  20081201 21:40:39

Ryan May wrote: > 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 onesided 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. Hi Ryan, I appreciate the work you're doing on this, and while I don't have any very strong opinions on the API questions you raise, I would request that you include in the docstrings information at least at the level of the above, listing the scaling issue, the sources you've followed and how and why you've chosen to follow them or deviate, and differences with the default behavior of other software. I recently helped a colleague use Matlab's PSD/pwelch functions and had to spend some time sending in sine waves of various frequencies and amplitudes to figure out what the results meant. If matplotlib gives different results by default, I think it should 1) justify why and 2) indicate what option(s) may be set to get results equivalent to other systems, including Matlab. Thanks again, Andrew 
From: twentypoundtrout <twentypoundtrout@ya...>  20081201 21:40:16

Alan G Isaac wrote: > > 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? > > I don't think that it communicates any more information, but it can often add depth to an otherwise benign figure and can also make the presentation softer to view. Just makes if fancy I guess.  View this message in context: http://www.nabble.com/plotwithdropshadowtp20773979p20781124.html Sent from the matplotlib  users mailing list archive at Nabble.com. 
From: John Hunter <jdh2358@gm...>  20081201 21:39:58

On Mon, Dec 1, 2008 at 2:43 PM, twentypoundtrout <twentypoundtrout@...> wrote: > So there is no way to say plot a line. Grab that image. Apply a standard > SVG filter (like Gaussian). And overlay the blur? I do not know the PIL > well enough to know if this is feasible. You can do this using an external program  see for example http://abitofpythonabitofastronomy.blogspot.com/2008/10/svg.html. It would be challenging to implement something like this internally across output formats I think, but we recently added some features to make it easier to use an svg editor for filtering mpl objects. See also this thread http://www.nabble.com/SVGclickableimagestd20236869.html#a20236869 JDH 
From: Alan G Isaac <aisaac@am...>  20081201 21:25:37

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 
From: Mike Hearne <mhearne@us...>  20081201 21:12:16

Along similar lines, has anyone figured out a way to have a drop shadow effect for text on a plot? twentypoundtrout <twentypoundtrout@...> 12/01/08 01:43 PM To matplotlibusers@... cc Subject Re: [Matplotlibusers] plot with drop shadow John Hunter4 wrote: > > On Mon, Dec 1, 2008 at 9:17 AM, Nate <tenpoundwalleye@...> wrote: >> Is there a way to plot lines with drop shadows? >> > > Nothing builtin  but you can fake it:: > > import matplotlib.pyplot as plt > import numpy as np > > t = np.arange(0.0, 2.0, 0.01) > s = np.sin(2*np.pi*t) > > fig = plt.figure() > ax = fig.add_subplot(111) > ax.plot(t+0.01, s0.01, color='gray', lw=2) > ax.plot(t, s, color='blue', lw=3) > plt.show() > > JDH > > So there is no way to say plot a line. Grab that image. Apply a standard SVG filter (like Gaussian). And overlay the blur? I do not know the PIL well enough to know if this is feasible.  View this message in context: http://www.nabble.com/plotwithdropshadowtp20773979p20780129.html Sent from the matplotlib  users mailing list archive at Nabble.com.  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://moblincontest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlibusers mailing list Matplotlibusers@... https://lists.sourceforge.net/lists/listinfo/matplotlibusers 
From: Ryan May <rmay31@gm...>  20081201 20:58:56

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 onesided 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 
From: twentypoundtrout <twentypoundtrout@ya...>  20081201 20:43:13

John Hunter4 wrote: > > On Mon, Dec 1, 2008 at 9:17 AM, Nate <tenpoundwalleye@...> wrote: >> Is there a way to plot lines with drop shadows? >> > > Nothing builtin  but you can fake it:: > > import matplotlib.pyplot as plt > import numpy as np > > t = np.arange(0.0, 2.0, 0.01) > s = np.sin(2*np.pi*t) > > fig = plt.figure() > ax = fig.add_subplot(111) > ax.plot(t+0.01, s0.01, color='gray', lw=2) > ax.plot(t, s, color='blue', lw=3) > plt.show() > > JDH > > So there is no way to say plot a line. Grab that image. Apply a standard SVG filter (like Gaussian). And overlay the blur? I do not know the PIL well enough to know if this is feasible.  View this message in context: http://www.nabble.com/plotwithdropshadowtp20773979p20780129.html Sent from the matplotlib  users mailing list archive at Nabble.com. 
From: John Hunter <jdh2358@gm...>  20081201 20:02:19

On Mon, Dec 1, 2008 at 1:08 PM, Eric Emsellem <emsellem@...> wrote: > Hi > > this may be a known problem (didn't find anything on this issue) but here it is: > >  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... > > The problem is that it is almost impossible to reproduce a systematic behaviour > there so I cannot really send you a list of commands which results in a crash. > It just happens (often). However, after someone suggested it, I now enter > Ipython by a simple "ipython" and do immediately "from pylab import *". And then > I have NO crashes whatsoever. > > any suggestion there? Is that normal? It is definitely not normal  it almost never happens to me. Does it help if you run TkAgg instead of GTKAgg. Are you importing/using anything else when this is happening? What version of numpy are you running? 
From: Matt Foster <matt.p.foster@gm...>  20081201 20:01:17

On Wed, Nov 26, 2008 at 7:11 AM, Nils Wagner <nwagner@...> 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 ? Is: from pylab import ylim, ytics figure(2) polar(theta,(r+noise)/r) ylim(0, 2) yticks(arange(0, 2, 0.25)) show() The kind of thing you're after? Cheers, Matt  Matt Foster  http://hackerific.net 
From: Christopher Barker <Chris.Barker@no...>  20081201 19:54:42

Jesper Larsen wrote: > I have a web application in which I would like to scale the plots down > if the users horizontal screen size is less than 800. http://www.scipy.org/Cookbook/Matplotlib/AdjustingImageSize Chris  Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception Chris.Barker@... 
From: Eric Emsellem <emsellem@ob...>  20081201 19:53:17

Hi this may be a known problem (didn't find anything on this issue) but here it is:  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... The problem is that it is almost impossible to reproduce a systematic behaviour there so I cannot really send you a list of commands which results in a crash. It just happens (often). However, after someone suggested it, I now enter Ipython by a simple "ipython" and do immediately "from pylab import *". And then I have NO crashes whatsoever. any suggestion there? Is that normal? thanks Eric P.S.: OpenSuse 11.0 or 10.3 (two machines showing similar behaviour) matplotlib version 0.98.3 verbose.level helpful interactive is True units is True platform is linux2 backend GTKAgg version 2.10.6 Python 2.5.1 (r251:54863, Aug 1 2008, 00:35:20) IPython 0.8.1  An enhanced Interactive Python. 
From: Ryan May <rmay31@gm...>  20081201 18:20:09

Ryan May wrote: > Fago, Matt  AES wrote: >> I found bug number 1859027 and have appended the below to the bug report. >> >> When is the next release due and how likely is this to get fixed? I >> might have time myself >> to help in a week or so, but would appreciate some help if someone >> else has time too (who >> has looked at the source before...) > > I'm sitting down to look at this right now. Can you tell me if you have > this problem with 0.98.3 as well? Nevermind, I just realized you can't really do the example without the new support for pad_to. I'm still looking... Ryan  Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma 
From: Ryan May <rmay31@gm...>  20081201 17:58:50

Fago, Matt  AES wrote: > I found bug number 1859027 and have appended the below to the bug report. > > When is the next release due and how likely is this to get fixed? I might have time myself > to help in a week or so, but would appreciate some help if someone else has time too (who > has looked at the source before...) I'm sitting down to look at this right now. Can you tell me if you have this problem with 0.98.3 as well? Thanks, Ryan Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma 
From: Manuel Metz <mmetz@as...>  20081201 16:26:16

Manuel Metz wrote: > Alejandro Weinstein wrote: >> On Mon, Dec 1, 2008 at 7:13 AM, Manuel Metz <mmetz@...> wrote: >>> You can use the keyword "numpoints" in the legend method: >> Thank you! It did the trick. >> >> Now how you conclude that from the documentation is a mystery: >> >> >From the docs: >> " >> numpoints: integer >> The number of points in the legend line, default is 4" > > Ah, that's apparently a bug in the docs, which I've fixed in the sources. I have to correct myself. John Hunter applied a patch which fixed the docs. >> Regards, >> Alejandro. >> >>  >> 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://moblincontest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Matplotlibusers mailing list >> Matplotlibusers@... >> https://lists.sourceforge.net/lists/listinfo/matplotlibusers > >  > 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://moblincontest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Matplotlibusers mailing list > Matplotlibusers@... > https://lists.sourceforge.net/lists/listinfo/matplotlibusers 
From: Fago, Matt  AES <Matt.Fago@it...>  20081201 16:03:42

I found bug number 1859027 and have appended the below to the bug report. When is the next release due and how likely is this to get fixed? I might have time myself to help in a week or so, but would appreciate some help if someone else has time too (who has looked at the source before...) Thanks, Matt ________________________________________ From: Fago, Matt  AES Sent: Tuesday, November 25, 2008 1:04 PM To: matplotlibusers@... Subject: Matplotlib PSD bug? [I'm not sure if this is best in 'devel' or 'users'] I'm trying to compute PSDs using matplotlib.mlab.psd and came across the "PSD amplitudes" thread from last year: http://sourceforge.net/mailarchive/message.php?msg_id=472101A6.9080206%40isla.hawaii.edu Using the latest version of psd on svn trunk (rev 6429) that added support for pad_to, I can now compute the Matlab pwelch example using matplotlib. This example is given in the Signal Processing Toolbox User's Guide: http://www.mathworks.com/access/helpdesk/help/pdf_doc/signal/signal_tb.pdf (look on pages 223 and 224). Note I do not have easy access to Matlab itself, so I'm just using this published example. The Matlab code is as follows: randn('state',1) fs = 1000; % Sampling frequency t = (0:0.3*fs)./fs; % 301 samples A = [2 8]; % Sinusoid amplitudes (row vector) f = [150;140]; % Sinusoid frequencies (column vector) xn = A*sin(2*pi*f*t) + 5*randn(size(t)); Hs = spectrum.welch('rectangular',150,50); psd(Hs,xn,'Fs',fs,'NFFT',512); This produces a fairly noisy signal from 20 to 10 dB, with a strong peak of ~6 dB at 150 Hz (see the plot on page 224). While my equivalent (?) python code is: from scipy import * from mlabsvn import psd # This is a local copy of svn revision 6429 of matplotlib.mlab from pylab import * fs=1000 t=linspace(0,0.3,0.3*fs+1) A=[2,8] f=[150,140] xn=A[0]*sin(2*pi*f[0]*t) + A[1]*sin(2*pi*f[1]*t) + 5*randn(len(t)) Pxx,freqs = psd(xn,Fs=fs,NFFT=150,noverlap=75,pad_to=512) figure() plot(freqs, 10*log10(Pxx) ) show() However, this produces a peak of over 30 dB at 150 Hz. Unless there is a mistake in my code above, there seems to be a significant difference between the matplotlib and matlab implementations. I noticed that the values 10*log10(Pxx/len(xn)) produces results that match much better. Without looking more closely at the code for psd and reviewing Bendat and Piersol I cannot be sure that this is the correct fix. Does anyone else have any insight? When is the next release planned, and how likely is a fix? Thanks, Matt This email 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 email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this email and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this email. 
From: Jeff Whitaker <jswhit@fa...>  20081201 16:03:39

Hrafnkell Pálsson wrote: > Any chance of further help? > John? > > Hrafnkell > Hrafnkell: I'm pretty sure this is a fundamental limitation of canvas.restore_region  everything gets draw on top of it. If I recall correctly, you'd like to save the map with coastlines drawn, and just redraw contours on it. If you're reusing a Basemap instance, I'd be surprised if the time spent redrawing the coastlines is all that significant. Are you? Creating the coastline polygons in map projection coordinates is the most expensive operation, but that is done when the Basemap instance is created. Another option would be to just remove the contours from the figure, then redraw the new ones and resave the figure, i.e. from mpl_toolkits.basemap import Basemap import matplotlib.pyplot as plt # create new figure fig=plt.figure() # setup of of mollweide Basemap. m = Basemap(resolution='c',projection='moll',lon_0=0) # draw some contours. x, y = m(lons, lats) # get map projection coords of lat/lon grid CS = m.contour(x,y,data,15,linewidths=0.5,colors='k') # draw coastlines and projection limb. m.drawcoastlines() m.drawmapboundary() # save figure with contours. plt.savefig('fig1.png') # remove contours, save figure again. for coll in CS.collections: coll.remove() plt.savefig('fig2.png') # draw contours again, this time red, save figure a third time. CS = m.contour(x,y,data,15,linewidths=0.5,colors='r') plt.savefig('fig3.png') HTH, Jeff  Jeffrey S. Whitaker Phone : (303)4976313 Meteorologist FAX : (303)4976449 NOAA/OAR/PSD R/PSD1 Email : Jeffrey.S.Whitaker@... 325 Broadway Office : Skaggs Research Cntr 1D113 Boulder, CO, USA 803033328 Web : http://tinyurl.com/5telg 
From: twentypoundtrout <twentypoundtrout@ya...>  20081201 16:02:22

Mauro Cavalcanti wrote: > > The above code works quite well. However, I do *not* want to have the > plot done for each edge inside the for loop; instead, I would like to > have the x,y points stored for being plotted at once, using a plot > command issued outside the loop. It seems that it could be done using > MPL line collections, but I could not figure out how to do this. Any > hints? > You can plot the columns of a X/Y data using one plot command here: from pylab import * nodes = load('nodes.dat') edges = int16(load('edges.dat'))  1 x = nodes[edges,0].transpose() y = nodes[edges,1].transpose() plot(x,y,'bo') show()  View this message in context: http://www.nabble.com/Plottingedgesbetweennodestp20708135p20774488.html Sent from the matplotlib  users mailing list archive at Nabble.com. 
From: John Hunter <jdh2358@gm...>  20081201 15:58:45

On Mon, Dec 1, 2008 at 9:17 AM, Nate <tenpoundwalleye@...> wrote: > Is there a way to plot lines with drop shadows? > Nothing builtin  but you can fake it:: import matplotlib.pyplot as plt import numpy as np t = np.arange(0.0, 2.0, 0.01) s = np.sin(2*np.pi*t) fig = plt.figure() ax = fig.add_subplot(111) ax.plot(t+0.01, s0.01, color='gray', lw=2) ax.plot(t, s, color='blue', lw=3) plt.show() JDH 