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
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
1
(5) |
2
(24) |
3
(2) |
4
|
5
(4) |
6
(1) |
7
(22) |
8
(9) |
9
(23) |
10
(6) |
11
|
12
(7) |
13
(17) |
14
(12) |
15
(10) |
16
(22) |
17
(11) |
18
(6) |
19
(11) |
20
(13) |
21
(10) |
22
(7) |
23
(7) |
24
(5) |
25
(3) |
26
(20) |
27
(17) |
28
(25) |
29
(16) |
30
(17) |
31
(8) |
On Mar 29, 2007, at 2:49 PM, Iyer wrote: > > Thanks for your response, what I'm trying to find - is a way to > have the whole subplot stop displaying non-data related parts of > it, like when we use the back and forward arrows on the matplotlib > toolbar, the subplot goes off the boundaries and can display as > white space (or the color of the subplot background). > > Please find attached an image - hope this will better illustrate > what I was trying to convey. If the subplot in the image stops > "scrolling" or rolling when it's boundaries are reached, it would > be nice. Ah, I think understand what you're looking for now. You want the pylab toolbar to stop panning when you reach the end of the data range instead of continuing over into an empty area. Does that sound right to you? > I was trying to find if the whole subplot could be enclosed within > a scrollbar, JDH says that is not possible. I believe you may have been asking the wrong question. ;-) Based on my understanding of things it should be possible to add this feature to the toolbar, assuming one can easily determine the bounding box of the plot in axes coordinates. One of the devs might be able to implement it for you, although I obviously cannot speak for them. Ken
Peter Melchior wrote: > Hello, > > I understand that hold() creates a axes if there is none. > What I want to do is plotting a couple of plots in each of the subplots. > > The data I want to display is stored in a set of files, thus I have a > loop of plot calls in each subplot: > > hold(True) > subplot(311) > for i in range(8): > bins = somefunction(i) > data = someotherfunction(i) > plot(bins,data) > subplot(312) > for i in range(8): > ... > > That's why I want to ensure that hold is set to True. > Is there a better way of achieving that? One way is this: ax = subplot(311) ax.hold(True) Or this: subplot(311) hold(True) The plot command will not change the hold state unless you tell it to by giving it a hold kwarg, in which case it will only temporarily change it--the change will not affect the next plot command. Another way is to set the default via the rcParams array, as in many of the example scripts that come with the source distribution, or via the matplotlibrc file. In both cases, it is the axes.hold parameter. The default is True, so unless you have a non-default matplotlibrc file, you should be getting the behavior you want without having to do anything at all. Still, setting it explicitly in your script is a good idea because it makes it clear what is going on, and it makes the script immune to changes in the matplotlibrc file. Eric > > Best regards, > > Peter Melchior > > > > Eric Firing wrote: >> The pylab hold command sets the hold variable for the current axes. >> If there is none, it makes one, hence the full-size axes on which your >> subplots are superimposed. The hold variable determines whether >> subsequent calls to something like "plot" erase the axes first, or >> superimpose their drawing on whatever was already there. >> >> What is it you are really trying to do? >> >> Eric >> >> Peter Melchior wrote: >>> Hello everybody, >>> >>> when using this very simple script, I get three subplots which lie on >>> top of a >>> empty plot covering the whole area of the figure: >>> >>> from numpy import * >>> from pylab import * >>> >>> hold(True) >>> subplot(311) >>> subplot(312) >>> subplot(313) >>> show() >>> >>> The result of this code can be viewed here: >>> https://www.ita.uni-heidelberg.de/~pmelchior/subplot_overlay.png >>> >>> If I leave out the line "hold(True)", which could also read >>> "hold(False)", the >>> underlying plot disappears. >>> >>> Is there a way to avoid that? Or: Is there a preferred position for >>> the "hold" >>> command? >>> >>> Best regards, >>> >>> Peter Melchior
forgot "reply to all"
Eric, Python 2.5 (precompiled binary) SciPy 0.5.2 (precompiled binary) matplotlib 0.8737 (win32-py2.5 precompiled binary) and if it matters I'm running in iPython for all this work. The script is: ---- from scipy import * from pylab import * import matplotlib.numerix.ma as ma N = 10 y = linspace(0, pi, N) x = linspace(0, pi, N) z = randn( N, N) zm = ma.masked_where( z > 0.3, z) pcolor( x, y, zm) ---- and the result I get is: ---- In [11]: execfile('pcolor_issue.py') --------------------------------------------------------------------------- <type 'exceptions.ValueError'> Traceback (most recent call last) C:\Documents and Settings\phays\My Documents\NDS\PDOP\<ipython console> in <module>() C:\Documents and Settings\phays\My Documents\NDS\PDOP\pcolor_issue.py in <module>() 7 x = linspace(0, pi, N) 8 z = randn( N, N) 9 zm = ma.masked_where( z > 0.3, z) 10 ---> 11 pcolor( x, y, z) C:\apps\py\lib\site-packages\matplotlib\pylab.py in pcolor(*args, **kwargs) 1941 hold(h) 1942 try: -> 1943 ret = gca().pcolor(*args, **kwargs) 1944 draw_if_interactive() 1945 except: C:\apps\py\lib\site-packages\matplotlib\axes.py in pcolor(self, *args, **kwargs) 3788 raise TypeError, 'Illegal arguments to pcolor; see help(pcolor)' 3789 -> 3790 Nx, Ny = X.shape 3791 3792 # convert to MA, if necessary. <type ' exceptions.ValueError'>: need more than 1 value to unpack ---- On 3/29/07, Eric Firing <ef...@ha...> wrote: > > Pcolor accepts non-integer values of X and Y, so I don't know what the > problem is. Please post a minimal but complete script that illustrates > the error, and say what version of mpl you are using. With moderately > recent versions, using masked arrays should work fine. > > Eric > > Park Hays wrote: > > I have bogus values I don't want to display in a gridded data set > > (regions of non-convergence, for example). pcolor does exactly what I > > want with a masked array, except the X and Y arguments must be integer > > arrays (as far as I can tell) and my data X and Y points are not integer > > arrays. An approximation of what is happening goes like: > > > > x = linspace( 0, pi, 100) > > y = linspace( -pi/2, pi/2, 30) > > ev = custom_func( x, y) > > print sum( isnan( ev)) > > 12 (or whatever) > > > > ev_m = ma.mask_where( isnan( ev), ev) > > pcolor( x, y, ev_m) <-- this will fail, with an error like "need more > > than one value to unpack" which I think is caused by the non-integer > > nature of x, y. > > > > > > Any suggestions for how can I can address this? My preference is to use > > pcolor, because of the transparency. I am not a fan of the scipy > > discussion regarding user-driven normalization "sentinels" to catch the > > bogus values. Masked arrays seem so much more flexible. > > > > -Park > >
The pylab hold command sets the hold variable for the current axes. If there is none, it makes one, hence the full-size axes on which your subplots are superimposed. The hold variable determines whether subsequent calls to something like "plot" erase the axes first, or superimpose their drawing on whatever was already there. What is it you are really trying to do? Eric Peter Melchior wrote: > Hello everybody, > > when using this very simple script, I get three subplots which lie on top of a > empty plot covering the whole area of the figure: > > from numpy import * > from pylab import * > > hold(True) > subplot(311) > subplot(312) > subplot(313) > show() > > The result of this code can be viewed here: > https://www.ita.uni-heidelberg.de/~pmelchior/subplot_overlay.png > > If I leave out the line "hold(True)", which could also read "hold(False)", the > underlying plot disappears. > > Is there a way to avoid that? Or: Is there a preferred position for the "hold" > command? > > Best regards, > > Peter Melchior > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Pcolor accepts non-integer values of X and Y, so I don't know what the problem is. Please post a minimal but complete script that illustrates the error, and say what version of mpl you are using. With moderately recent versions, using masked arrays should work fine. Eric Park Hays wrote: > I have bogus values I don't want to display in a gridded data set > (regions of non-convergence, for example). pcolor does exactly what I > want with a masked array, except the X and Y arguments must be integer > arrays (as far as I can tell) and my data X and Y points are not integer > arrays. An approximation of what is happening goes like: > > x = linspace( 0, pi, 100) > y = linspace( -pi/2, pi/2, 30) > ev = custom_func( x, y) > print sum( isnan( ev)) > 12 (or whatever) > > ev_m = ma.mask_where( isnan( ev), ev) > pcolor( x, y, ev_m) <-- this will fail, with an error like "need more > than one value to unpack" which I think is caused by the non-integer > nature of x, y. > > > Any suggestions for how can I can address this? My preference is to use > pcolor, because of the transparency. I am not a fan of the scipy > discussion regarding user-driven normalization "sentinels" to catch the > bogus values. Masked arrays seem so much more flexible. > > -Park > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
On Mar 29, 2007, at 10:55 AM, Iyer wrote: > > That's unfortunate that a subplot cannot be bounded within a > scrollbar.. I guess if it could be possible to turn a subplot into > a GUI widget and have GUI widgets over another GUI widget (the > frame), that'd be good... I think that wouldn't be good at all, for a simple reason: matplotlib has no way of calculating how big a figure or subplot should be. Instead, it's up to the programmer to determine what the appropriate size is. It can also be tedious and error-prone to do fixed layouts with stacked widgets, depending on the GUI toolkit you're using. Because plotting is so flexible and matplotlib supports so many kinds of plots, I believe it would hard to come up with general algorithm to determine how big to make a figure or subplot. It gets even more complicated if you start considering things like resolution independent plotting -- different operating systems and displays can have dots-per-inch ratios and PNG or PS files will almost certainly have different DPIs than the graphical displays. > I was wondering how we can differentiate between data on a subplot > and the background. i.e, if there is a subplot such as: > > _________________________________ > | ______/\___ | > | / \ | > | \ | > |_________________________________| > > what could be the best way to predict where the subplot starts and > ends ? I'm afraid I can't read your diagram at all... Mac Mail might have mangled it. Personally, I think you ought to reconsider how you're designing your application. Scrolling subplots sounds like a really confusing interface to me. I think you might be a lot happier zooming in on interesting things with a mouse or splitting your plots up into multiple separate figures. Ken
I am sampling over the surface of a sphere. I evaluate a function at each position (like lat and lon or phi and theta)--the function I evaluate is fairly expensive. As a result I don't want to sample like: theta = linspace( -pi, pi, Ntheta) phi = linspace( 0, pi/2, Nphi) since theta will be grossly oversampled near the poles. There are a lot of solutions to this, but all require modifying the sampling near the poles. I use something I call "geodesic sampling", but there are other approaches. See http://newsreader.mathworks.com/WebX/.ef0dfad?50...@44...Vebg6y5bv@ for some talk on the concept. The crappy thing about working in these irregular sample spaces is that visualization is very difficult. I would be delighted to use Basemap in conjunction with these, but my understanding is that Basemap requires a regular grid. Scatter plots (with the value attribute assigned to color or marker size) are still mediocre because the user loses the sense of connectivity between the points. Any thoughts on: resampling an irregular grid? displaying and graphing? -Park
I have bogus values I don't want to display in a gridded data set (regions of non-convergence, for example). pcolor does exactly what I want with a masked array, except the X and Y arguments must be integer arrays (as far as I can tell) and my data X and Y points are not integer arrays. An approximation of what is happening goes like: x = linspace( 0, pi, 100) y = linspace( -pi/2, pi/2, 30) ev = custom_func( x, y) print sum( isnan( ev)) 12 (or whatever) ev_m = ma.mask_where( isnan( ev), ev) pcolor( x, y, ev_m) <-- this will fail, with an error like "need more than one value to unpack" which I think is caused by the non-integer nature of x, y. Any suggestions for how can I can address this? My preference is to use pcolor, because of the transparency. I am not a fan of the scipy discussion regarding user-driven normalization "sentinels" to catch the bogus values. Masked arrays seem so much more flexible. -Park
Hello everybody, when using this very simple script, I get three subplots which lie on top of a empty plot covering the whole area of the figure: from numpy import * from pylab import * hold(True) subplot(311) subplot(312) subplot(313) show() The result of this code can be viewed here: https://www.ita.uni-heidelberg.de/~pmelchior/subplot_overlay.png If I leave out the line "hold(True)", which could also read "hold(False)", the underlying plot disappears. Is there a way to avoid that? Or: Is there a preferred position for the "hold" command? Best regards, Peter Melchior
That's unfortunate that a subplot cannot be bounded within a scrollbar.. I guess if it could be possible to turn a subplot into a GUI widget and have GUI widgets over another GUI widget (the frame), that'd be good... I was wondering how we can differentiate between data on a subplot and the background. i.e, if there is a subplot such as: _________________________________ | ______/\___ | | / \ | | \ | |_________________________________| what could be the best way to predict where the subplot starts and ends ? thanx, iyer John Hunter <jd...@gm...> wrote: On 3/26/07, lazardo wrote: > > Thanks for your helpful response. > > I used wx, I'm mystified to as how to make the scroll bars bound the > subplot. not the frame. The gtk example you pointed me to creates horizontal > and vertical scrollbars around the whole frame, not within the subplot. > i.e., if the subplot is very large , scrollbars bounding the subplot would > be great.. This is not possible. The subplot is not a GUI widget in matplotlib, it is part of the entire FigureCanvas, which is a widget. You can make the Axes take up all of the figure area if you want ax = axes([0,1,0,1]) but then you will not see you tick labels and axis labels as they will be outside the canvas area.... JDH --------------------------------- Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games.
Hi all, I'd like to suggest an improvement to the plot window when used from GTK. I'm using Matplotlib 0.87.5, so perhaps this has already been fixed, not sure. The issue is a small thing with usability when saving files of different types. I most often save my plots as EPS or PNG files but sometimes SVG. The issue is that the default file type is "PNG", and the save window doesn't make any correct to that default, even if I type "myplot.eps". I think that the best behaviour would be * if I type a (valid) file extension, use that as the file type * if I don't type any file extension, use the selected one (and default to PNG) * if I type and extension and then change the filetype dropdown, the extension I typed should be changed to match the selected filetype. If someone could point me at the relevant bit of code I could have a go at doing it myself, else I'd be happy to test it or whatever. Cheers JP -- John Pye Department of Mechanical and Manufacturing Engineering University of New South Wales, Sydney, Australia http://pye.dyndns.org/
I've installed in my machine in the following order python 2.5 numpy 1.01 matplot lib 0.87 scipy 0.52 wxPython 2.8 with no problem I've also installed the same packages at home and in another two computer and everything went fine. The I was asked to install this "configuaration" in some classroom machines and also on another computer and I continue getting this error The import of the numpy version of the _transforms module, _ns_transforms, failed. This is is either because numpy was unavailable when matplotlib was compiled, because a dependency of _ns_transforms could not be satisfied, or because the build flag for this module was turned off in setup.py. If it appears that _ns_transforms was not built, make sure you have a working copy of numpy and then re-install matplotlib. Otherwise, the following traceback gives more details: Traceback (most recent call last): File "<pyshell#2>", line 1, in <module> from pylab import * File "C:\Python25\Lib\site-packages\pylab.py", line 1, in <module> from matplotlib.pylab import * File "C:\Python25\Lib\site-packages\matplotlib\pylab.py", line 201, in <module> from axes import Axes, PolarAxes File "C:\Python25\Lib\site-packages\matplotlib\axes.py", line 14, in <module> from artist import Artist, setp File "C:\Python25\Lib\site-packages\matplotlib\artist.py", line 4, in <module> from transforms import identity_transform File "C:\Python25\Lib\site-packages\matplotlib\transforms.py", line 223, in <module> from _transforms import Value, Point, Interval, Bbox, Affine File "C:\Python25\Lib\site-packages\matplotlib\_transforms.py", line 17, in <module> from matplotlib._ns_transforms import * ImportError: DLL load failed: Impossibile trovare il modulo specificato but I can assure that If I check numpy installation before installing matplot lib it seems everything fine. All computer have Windows XP home edition 2002 SP2 the only difference is in the RAM quantity. (more than 256 in the computer where everything works) but it seems so strange to me that it is the ram (I've also installed in another computer , old one, and everything works) Any IDEA ???? Thanks in advance for any suggestion Giorgio
Hi, After a few trials and errors I could finally set up plots the way I wanted by modifying the matplotlibrc resource. In an essence, I want bright information (fonts,lines) on dark background (figure bg, axes bg) and I can fully achieve this goal while DISPLAYING plots. However, SAVING damages their colors ingloriously (I could not trace down the rule what is aimed to be achieved) and tweaking the two options in the example matplotlibrc (savefig.facecolor and savefig.edgecolor) would not help. In matlab there is a switch to disable color inversion for hard copies: anything equivalent in the (otherwise excelent) matlibplot? Thanks a lot, Dominik -- Dominik Szczerba, PhD Computer Vision Lab CH-8092 Zurich http://www.vision.ee.ethz.ch/~domi
On 3/28/07, Niklas Saers <nik...@gm...> wrote: > Hi guys, > I'm trying to make a specgram() for some wave samples that I have read into > 'data' using pyaudiolab's read_frames() (put into wavread()) > > When I do > > from wavread import * > from pylab import * > from statistics import * > > data, datasize, samplerate, channels = wavread("myfile.wav") > specgram(data) > > I get: > Warning: divide by zero encountered in log10 > (array([[ 2.26730611e-02, 1.51890672e-02, 7.78123371e-03, ..., > 0.00000000e+00, 0.00000000e+00, 0.00000000e+00], > [ 9.11969843e-03, 2.81931459e-03, 3.13995580e-03, ..., So there is no traceback, just a warning? Perhaps you could pickle or otherwise store "data" and write a simple test script which doesn't depend on any external packages (eg waveread) and post a link to the files and we'll take a look. My guess is that there is some frequency that has no power and the call to Z = 10*log10(Pxx) is failing because Pxx is zero for that frequency. We've seen this before, and if anyone has a suggestion on how this case *should* be handled, I'd be happy to hear some suggestions. JDH JDH