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
(13) 
2
(12) 
3
(3) 
4
(13) 
5
(13) 
6
(2) 
7
(5) 
8
(17) 
9
(9) 
10
(10) 
11
(16) 
12
(8) 
13
(10) 
14
(1) 
15
(5) 
16
(5) 
17
(7) 
18
(13) 
19
(9) 
20

21

22
(2) 
23
(3) 
24
(5) 
25
(5) 
26
(14) 
27
(1) 
28
(2) 
29
(18) 
30
(5) 
31
(22) 



From: Adam Mercer <ramercer@gm...>  20071011 22:31:33

On 11/10/2007, Jeff Whitaker <jswhit@...> wrote: > but I think you want > > values, lon = basemap.shiftgrid(180, values, lon, start=False) Thats it! Thanks a lot! Cheers Adam 
From: Joshua J. Kugler <joshua@ee...>  20071011 22:12:01

Disclaimer: I do know Python, but am not terribly familiar with Matplotlib as I'm taking over the maintenance of our graphing libraries. This post is likely to leave out details that you need to help diagnose the problem, but I didn't think posting all 1500 or so lines of our graphing routines would be that helpful at this point. :) As you can see from the attached graph, there is a break the in graph somewhere around 7 AM or so. This is the data I am graphing for that red line: "20071009 00:00:00",0.015 "20071009 01:00:00",0.015 "20071009 02:00:00",0.014 "20071009 03:00:00",0.012 "20071009 04:00:00",0.008 "20071009 05:00:00",0.002 "20071009 06:00:00",0.006 "20071009 07:00:00",1.068 "20071009 08:00:00",12.8 "20071009 09:00:00",15.21 "20071009 10:00:00",20.13 "20071009 11:00:00",20.94 "20071009 12:00:00",21.15 "20071009 13:00:00",21.13 "20071009 14:00:00",20.88 "20071009 15:00:00",20.72 "20071009 16:00:00",20.55 "20071009 17:00:00",16.28 "20071009 18:00:00",13.18 "20071009 19:00:00",4.342 "20071009 20:00:00",0.016 "20071009 21:00:00",0.015 "20071009 22:00:00",0.015 "20071009 23:00:00",0.015 If I change the 0.006 at 6:00AM to 0.006, it graphs with no break in the line. This is not a big deal to me, but it is a big deal to the consumer of these graphs. Could this be a bug in matplotlib, or is it more likely a bug in what we're doing with the data (almost nothing) before it gets to the matplotlib graphing routines? Thanks for any insight you can give. j  Joshua Kugler Lead System Admin  Senior Programmer http://www.eeinternet.com PGP Key: http://pgp.mit.edu/ ID 0xDB26D7CE PO Box 80086  Fairbanks, AK 99708  Ph: 9074565581 Fax: 9074563111 
From: Jeff Whitaker <jswhit@fa...>  20071011 22:08:34

Adam Mercer wrote: > On 11/10/2007, Jeff Whitaker <jswhit@...> wrote: > > >> Adam: I assume your data is on a latitudelongitude grid? You've asked >> for a mollweide projection centered on the Greenwich meridian. Your >> data is not centered on Greenwich  but the error message is trying to >> say that you can shift your grid (with the shiftgrid function) so that >> is has the same orientation as the map projection region. This only >> comes into play with global projections that 'wraparound' at the edges, >> like the mollweide and mercator projections. The orthographic >> projection does not 'wrap around'  hence you don't get the error message. >> > > Looking at the shiftmap function it looks like I should shift the > coordinate grid so that my longitude runs from 180 to 180 instead of > 0 to 360, therefore the following shiftgrid call should do this > > values, lon = basemap.shiftgrid(180, values, lon) > > However I still get the same error and the corruption in the resulting > plot. I feel like I'm missing something obvious here but can't find > it. > > Cheers > > Adam > Adam: From the basemap docs; shiftgrid(lon0, datain, lonsin, start=True) shift global lat/lon grid east or west. assumes wraparound (or cyclic point) is included. lon0: starting longitude for shifted grid (ending longitude if start=False). lon0 must be on input grid (within the range of lonsin). datain: original data. lonsin: original longitudes. start[True]: if True, lon0 represents the starting longitude of the new grid. if False, lon0 is the ending longitude. returns dataout,lonsout (data and longitudes on shifted grid). You did values, lon = basemap.shiftgrid(180, values, lon) but I think you want values, lon = basemap.shiftgrid(180, values, lon, start=False) 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 1D124 Boulder, CO, USA 803033328 Web : http://tinyurl.com/5telg 
From: John Hunter <jdh2358@gm...>  20071011 20:54:02

On 10/11/07, Alexander Schmolck <a.schmolck@...> wrote: > Hi, > > I'm using matplotlib in a C++ app (with a qt4 gui), by embedding python with > boost::python. The C++ app calls Py_Initialize(), init_myplottingmodule(), and > boost::python::import("matplotlib.pylab") once on startup and certain GUI > events then fire up a matplotlib window via calls like this one: > > // simplified version > void plotCurve(){ > clf(); > title("Diagonal line plot"); > double O1[] = {0,1}; > plot(std::vector<double>(O1,O1+2), std::vector<double>(O1,O1+2), "b:"); > show(); Eeeeew, that looks really dangerous. For starters, I would never try to do this using pylab, but rather follow the lead of examples/embedding_in_qt.py. Then you won't be competing for the mainloop.... JDH 
From: John Hunter <jdh2358@gm...>  20071011 19:33:15

On 10/11/07, Charles Seaton <cseaton@...> wrote: > Any suggestions on how to get either matplotlib.dates.datestr2num or > dateutil.parser.parse to properly handle timezone information in the > datestring would be greatly appreciated. Not sure how to answer this question visavid dateutil.parser, but you may want to consider creating your own datestr > datetime converter using time.strptime and then allowing mpl to convert to numbers using date2num. I think you can use the %Z format code for timezones. JDH 
From: Charles Seaton <cseaton@st...>  20071011 19:23:47

I am having some problems getting matplotlib.dates.datestr2num to handle timezones in the datestring. >import matplotlib >matplotlib.dates.datestr2num('Jan 1, 2007 12:00 PDT') 732677.83333333337 >matplotlib.dates.datestr2num('Jan 1, 2007 12:00 PST') 732677.83333333337 >matplotlib.dates.datestr2num('Jan 1, 2007 12:0008') 732677.83333333337 >matplotlib.dates.datestr2num('Jan 1, 2007 12:00 UTC') 732677.5 >matplotlib.dates.datestr2num('Jan 1, 2007 12:00 EST') 732677.5 >matplotlib.dates.datestr2num('Jan 1, 2007 12:0007') 732677.79166666663 The problem appears to lie with dateutil, as direct use of the dateutil.parser.parse function shows the same problem: > import dateutil.parser > dateutil.parser.parse('Jan 1, 2007 12:00 EST') datetime.datetime(2007, 1, 1, 12, 0) > dateutil.parser.parse('Jan 1, 2007 12:00 PDT') datetime.datetime(2007, 1, 1, 12, 0, tzinfo=tzlocal()) > dateutil.parser.parse('Jan 1, 2007 12:00 PST') datetime.datetime(2007, 1, 1, 12, 0, tzinfo=tzlocal()) I am using dateutil version 1.2. Any suggestions on how to get either matplotlib.dates.datestr2num or dateutil.parser.parse to properly handle timezone information in the datestring would be greatly appreciated. Charles Seaton OHSU/CMOP  View this message in context: http://www.nabble.com/datestr2num%2Cdateutil.parseandtimezoneproblemstf4609462.html#a13162968 Sent from the matplotlib  users mailing list archive at Nabble.com. 
From: <alain.pean@ce...>  20071011 19:10:14

Hi Yadin, I am a simple user, but I already faced this problem. The idea I used is to plot the data as an image, with magnitudes being converted in color levels. To do that, you have to define an array (let's say 'Z', Z(x,y) with dims len(X) and len(Y) and fill it with tour magnitudes. Then you have a two dimensional array that you display as an image using : im = pylab.Imshow(Z) Imshow has a lot of options you can use to customize your display, and you can add a colorbar with : pylab.colorbar() I have some examples of such scripts, but commented in French, so perhaps not very useful for you. See the user's guide to begin, p 38 for example. Regards, Alain yadin Bocuma Rivas a écrit : > > I i have tree lists or array of values > list x of 100... values > list y of 100.. values > list mag of 100.. values > list x and y are coordiantes of points > and list Mag is magnitude of something at that point > > how can i plot this quantities using matplotlib, any function please? > > my code starts as.....i need to plot the points vhat can i use? > > from __future__ import division > from matplotlib.patches import Patch > from pylab import * > > def func3(x,y): > return (1 x/2 + x**5 + y**3)*exp(x**2y**2) > > > # make these smaller to increase the resolution > dx, dy = 0.5, 0.5 > > X = arange(3.0, 3.0001, dx) > > Y = arange(3.0, 3.0001, dy) > > Mag= X**2+Y**2 > > ?????(X, Y, Mag) > colorbar() > axis([3,3,3,3]) > savefig('three d plot of points making a surface') > show() > > >  > > ¡Sé un mejor ambientalista! > Encuentra consejos para cuidar el lugar donde vivimos en: > http://telemundo.yahoo.com/promos/mejorambientalista.html > > >  > > ¡Sé un mejor besador! > Comparte todo lo que sabes sobre besos en: > http://telemundo.yahoo.com/promos/mejorbesador.html >  > >  > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ >  > > _______________________________________________ > Matplotlibusers mailing list > Matplotlibusers@... > https://lists.sourceforge.net/lists/listinfo/matplotlibusers > 
From: Adam Mercer <ramercer@gm...>  20071011 18:33:27

On 11/10/2007, Jeff Whitaker <jswhit@...> wrote: > Adam: I assume your data is on a latitudelongitude grid? You've asked > for a mollweide projection centered on the Greenwich meridian. Your > data is not centered on Greenwich  but the error message is trying to > say that you can shift your grid (with the shiftgrid function) so that > is has the same orientation as the map projection region. This only > comes into play with global projections that 'wraparound' at the edges, > like the mollweide and mercator projections. The orthographic > projection does not 'wrap around'  hence you don't get the error message. Looking at the shiftmap function it looks like I should shift the coordinate grid so that my longitude runs from 180 to 180 instead of 0 to 360, therefore the following shiftgrid call should do this values, lon = basemap.shiftgrid(180, values, lon) However I still get the same error and the corruption in the resulting plot. I feel like I'm missing something obvious here but can't find it. Cheers Adam 
From: Adam Mercer <ramercer@gm...>  20071011 18:05:41

On 11/10/2007, Jeff Whitaker <jswhit@...> wrote: > Adam: I assume your data is on a latitudelongitude grid? You've asked > for a mollweide projection centered on the Greenwich meridian. Your > data is not centered on Greenwich  but the error message is trying to > say that you can shift your grid (with the shiftgrid function) so that > is has the same orientation as the map projection region. This only > comes into play with global projections that 'wraparound' at the edges, > like the mollweide and mercator projections. The orthographic > projection does not 'wrap around'  hence you don't get the error message. Thanks, that makes sense now. Cheers Adam 
From: Jeff Whitaker <jswhit@fa...>  20071011 17:49:55

Adam Mercer wrote: > Hi > > I'm running into a problem using the mollweide projection, with the > following simplified code, my actual code doesn't use random data for > values but this is a clearer example to the problem I'm experiencing: > > lon = numpy.arange(0, 361, 1) > lat = numpy.arange(90, 91, 1) > x, y = numpy.meshgrid(lon, lat) > values = numpy.random.random((181, 361)) > > map = basemap.Basemap(projection='moll', lon_0=0, resolution='c') > map.drawcoastlines() > map.drawcountries() > map.drawmapboundary() > map.drawmeridians(numpy.arange(0,360,30)) > map.drawparallels(numpy.arange(90,90,30)) > > X, Y = map(x, y) > > map.contourf(X, Y, values) > > I get the following error: > > WARNING: x coordinate not montonically increasing  contour plot > may not be what you expect. If it looks odd, your can either > adjust the map projection region to be consistent with your data, or > (if your data is on a global lat/lon grid) use the shiftgrid > function to adjust the data to be consistent with the map projection > region (see examples/contour_demo.py). > > And the resulting map is incorrect due to the horizontal trends, see > http://tier2.ihepa.ufl.edu/~ram/files/moll.jpg > > > but if I use the orthographic projection ie: > > map = basemap.Basemap(projection='ortho', lat_0=20, lon_0=30, resolution='c') > > Then there are no errors, and the map is displayed as expected, see > http://tier2.ihepa.ufl.edu/~ram/files/ortho.jpg > > I am unsure as to why I am receiving this error for the mollweide > projection, as my coordinate grid is covering the entire surface. I > am clearly doing something wring here but I don't know what  does > anyone know what is causing this issue? > > Cheers > > Adam > Adam: I assume your data is on a latitudelongitude grid? You've asked for a mollweide projection centered on the Greenwich meridian. Your data is not centered on Greenwich  but the error message is trying to say that you can shift your grid (with the shiftgrid function) so that is has the same orientation as the map projection region. This only comes into play with global projections that 'wraparound' at the edges, like the mollweide and mercator projections. The orthographic projection does not 'wrap around'  hence you don't get the error message. 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 1D124 Boulder, CO, USA 803033328 Web : http://tinyurl.com/5telg 
From: yadin Bocuma Rivas <conra2004@ya...>  20071011 17:49:11

=0AI i have tree lists or array of values=0Alist x of 100... values=0Alist = y of 100.. values=0Alist mag of 100.. values=0Alist x and y are coordiantes= of points =0Aand list Mag is magnitude of something at that point=0A=0Ahow= can i plot this quantities using matplotlib, any function please?=0A=0Amy = code starts as.....i need to plot the points vhat can i use?=0A=0Afrom __fu= ture__ import division=0Afrom matplotlib.patches import Patch=0Afrom pylab = import *=0A=0Adef func3(x,y):=0A return (1 x/2 + x**5 + y**3)*exp(x**2= y**2)=0A=0A=0A# make these smaller to increase the resolution=0Adx, dy =3D= 0.5, 0.5=0A=0AX =3D arange(3.0, 3.0001, dx)=0A=0AY =3D arange(3.0, 3.000= 1, dy)=0A=0AMag=3D X**2+Y**2=0A=0A?????(X, Y, Mag)=0Acolorbar()=0Aaxis([3,= 3,3,3])=0Asavefig('three d plot of points making a surface')=0Ashow()=0A= =0A=0A=0A=0A=0A=0A =0A=A1S=E9 un mejor ambientalista!=0AEncuentra cons= ejos para cuidar el lugar donde vivimos en:=0A=0Ahttp://telemundo.yahoo.com= /promos/mejorambientalista.html=0A=0A=0A=0A=0A=0A ____________________= ________________________________________________________________=0A=A1S=E9 = un mejor fot=F3grafo!=0APerfecciona tu t=E9cnica y encuentra las mejores fo= tos. =0Ahttp://telemundo.yahoo.com/promos/mejorfotogr= afo.html 
From: Matthieu Brucher <matthieu.brucher@gm...>  20071011 16:35:48

> > Can this be changed? Is there a better approach I should take in > getting my students started using scipy and pylab together? > Teaching them what is a module and a namespace is a good think, why don't telling them to do : import pylab as pl import numpy as npy for instance so that they have a feeling it's almost like MAtlab, but better structured ? Matthieu 
From: Alexander Schmolck <a.schmolck@gm...>  20071011 16:34:08

Hi, I'm using matplotlib in a C++ app (with a qt4 gui), by embedding python with boost::python. The C++ app calls Py_Initialize(), init_myplottingmodule(), and boost::python::import("matplotlib.pylab") once on startup and certain GUI events then fire up a matplotlib window via calls like this one: // simplified version void plotCurve(){ clf(); title("Diagonal line plot"); double O1[] = {0,1}; plot(std::vector<double>(O1,O1+2), std::vector<double>(O1,O1+2), "b:"); show(); } Although this does sort of work, it doesn't work quite right. Specifically on clicking on the close button of the window, bad things frequently happen. For example, the first close seems to work, but subsequent attempts to close newly opened plots just zombify the window (it no longer repaints automatically but stays open; replots happen to that same window, i.e. the one that was opened second). Now I'm somewhat aware of all the nastiness of different event loops, the heroic efforts of ipython to make matplotlib work nicely interactively without blocking the REPL, but somehow I would have (naively) thought that all that work was just needed to avoid blocking. For the code above, blocking till the window would be closed is perfectly fine. Indeed that's what happens if I try something equivalent in the plain python shell (outside the C++ app). Any idea about the likely cause of the problem and what might be the simplest way to get it to work as expected (similar symptoms appear w/ matplotlib 0.87.7 and 0.91 under linux and osx)? cheers, 'as 
From: Adam Mercer <ramercer@gm...>  20071011 16:11:31

Hi I'm running into a problem using the mollweide projection, with the following simplified code, my actual code doesn't use random data for values but this is a clearer example to the problem I'm experiencing: lon = numpy.arange(0, 361, 1) lat = numpy.arange(90, 91, 1) x, y = numpy.meshgrid(lon, lat) values = numpy.random.random((181, 361)) map = basemap.Basemap(projection='moll', lon_0=0, resolution='c') map.drawcoastlines() map.drawcountries() map.drawmapboundary() map.drawmeridians(numpy.arange(0,360,30)) map.drawparallels(numpy.arange(90,90,30)) X, Y = map(x, y) map.contourf(X, Y, values) I get the following error: WARNING: x coordinate not montonically increasing  contour plot may not be what you expect. If it looks odd, your can either adjust the map projection region to be consistent with your data, or (if your data is on a global lat/lon grid) use the shiftgrid function to adjust the data to be consistent with the map projection region (see examples/contour_demo.py). And the resulting map is incorrect due to the horizontal trends, see http://tier2.ihepa.ufl.edu/~ram/files/moll.jpg but if I use the orthographic projection ie: map = basemap.Basemap(projection='ortho', lat_0=20, lon_0=30, resolution='c') Then there are no errors, and the map is displayed as expected, see http://tier2.ihepa.ufl.edu/~ram/files/ortho.jpg I am unsure as to why I am receiving this error for the mollweide projection, as my coordinate grid is covering the entire surface. I am clearly doing something wring here but I don't know what  does anyone know what is causing this issue? Cheers Adam 
From: John Hunter <jdh2358@gm...>  20071011 15:47:48

On 10/11/07, Ryan Krauss <ryanlists@...> wrote: > Can this be changed? Is there a better approach I should take in > getting my students started using scipy and pylab together? Yes, this was left in initially for backward compatibility but I think we should strive for maximal numpy compatibility going forward. In svn, we now have pyplot ehich is like pylab but minus the numpy stuff. Thus if you are using svn (or future releases) you can encourage your students to from scipy import * from matplotlib.pyplot import * 
From: Ryan Krauss <ryanlists@gm...>  20071011 15:39:02

I have successfully (I think) coerced my students into using Scipy/Numpy for signal processing and dynamic system modeling. They are mechanical engineering coming from a Matlab background. In order to make using Python easy and have it feel like Matlab, I teach them to put from scipy import * from pylab import * at the beginning of every script. One problem with this is that the zeros and ones functions of pylab default to integers while those from scipy default to floating point numbers. I have had several students this week beating there heads against problems that turned out to be trying to put floating point values in an array that was created using pylab.zeros. Can this be changed? Is there a better approach I should take in getting my students started using scipy and pylab together? Thanks, Ryan 