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
(10) |
2
(30) |
3
(11) |
4
(5) |
5
(14) |
6
(21) |
7
(19) |
8
(29) |
9
(23) |
10
(5) |
11
(3) |
12
(9) |
13
(6) |
14
(12) |
15
(10) |
16
(15) |
17
(5) |
18
(6) |
19
(4) |
20
(28) |
21
(8) |
22
(5) |
23
(10) |
24
(4) |
25
(1) |
26
(6) |
27
(13) |
28
(11) |
29
(9) |
30
(23) |
|
> > On 2005年9月07日, Eric Firing apparently wrote: > >>> So, the big question is: is it OK, or at least potentially >>> OK, to change the pylab API for contour and contourf so >>> that they return a single object instead of a tuple? > > > This breaks the matlab analogy. > I do not care about that myself, > but people coming from matlab might. > Maybe the right way to go is to provide an extended > contourgroup object > http://www.mathworks.com/access/helpdesk/help/techdoc/ref/contourgroupproperties.html > and treat contour and contourf as convenience functions that > continue to work as they do. > > fwiw, > Alan Isaac Alan, Actually, it shouldn't hurt people coming from matlab, for two reasons: 1) the present mpl contour and contourf don't return the same things that the matlab versions do, anyway; 2) Mathworks has already broken their users' matlab code by changing the contour/contourf return values between version 6 and version 7. The contourgroup is new in version 7. What I have in mind is similar to it--although until your message, I had completely forgotten that this is the thing that broke all my matlab contouring in version 7. So, the proposed change will make mpl contour less like matlab version 6 contour and more like version 7; but this is coincidental, not deliberate. Eric
On Thursday 08 September 2005 23:55, Jeff Whitaker wrote: > Nicolas: Sounds like you need to set numerix='numarray'. Try this at > the beginning of your script: > > from matplotlib import rcParams > rcParams['numerix']= 'numarray' > > -Jeff Jeff : a huge thanks for your damn fast answer ! I was so desperate that I had fired up IDL, which I hadn't done for months ! I'm so glad to be able to stick with matplotlib ! cheers, Nicolas
On 9/8/05, Mark Bakker <ma...@gm...> wrote: > I left the axis('scaled') option in, mostly as a novelty, and because I > like it. But it is only useful if you don't have subplots. Maybe we shoul= d > just get rid of it, as it is not really needed anymore. I have no idea wh= at > 'scaled' and 'equal' do together.=20 please keep it - as it works now axis('scaled') is similar to the matlab 'axis image' command, which is very useful. as explained in matlab: AXIS EQUAL sets the aspect ratio so that equal tick mark increments on the x-,y- and z-axis are equal in size. This makes SPHERE(25) look like a sphere, instead of an ellipsoid. AXIS IMAGE is the same as AXIS EQUAL except that the plot box fits tightly around the data. axis image is what you want if you like the grid axes to fit tightly around an image. when the figure window is resized you want the aspect ratio and the axis ranges preserved. when zooming in/out you want the aspect ratio preserved. Helge
Nicolas Girard wrote: >Hi all, >I need to use contour with data for x,y and z coordinates. My data is >contained in 3 numarray arrays called xi,z and rho. > >I can call contour with either of these 3 arrays without any problem. But when >it comes to pass the 3 arrays, here's the error I get: > >In [19]:contour(xi,z,rho) >--------------------------------------------------------------------------- >exceptions.TypeError Traceback (most recent >call last) > >/home/ngirard/.python/<console> > >/usr/lib/python2.4/site-packages/matplotlib/pylab.py in contour(*args, >**kwargs) > 1784 hold(h) > 1785 try: >-> 1786 ret = gca().contour(*args, **kwargs) > 1787 draw_if_interactive() > 1788 except: > >/usr/lib/python2.4/site-packages/matplotlib/axes.py in contour(self, *args, >**kwargs) > 1251 > 1252 def contour(self, *args, **kwargs): >-> 1253 return self._contourHelper.contour(*args, **kwargs) > 1254 contour.__doc__ = ContourSupport.contour.__doc__ > 1255 > >/usr/lib/python2.4/site-packages/matplotlib/contour.py in contour(self, *args, >**kwargs) > 675 tlinewidths = [(w,) for w in linewidths] > 676 >--> 677 C = _contour.Cntr(x, y, z.filled(), z.mask()) > 678 for level, color, width in zip(lev, tcolors, tlinewidths): > 679 nlist = C.trace(level, points = 1) > >TypeError: Arguments x, y, z, (optional) mask must be arrays. > > > > >I really don't understand where the problem is. All arrays are of the same >nature: > >In [20]:for a in [xi,z,rho]: > .20.: shape(a) > .20.: type(a) > .20.: >Out[20]:(1025, 1024) >Out[20]:<class 'numarray.numarraycore.NumArray'> >Out[20]:(1025, 1024) >Out[20]:<class 'numarray.numarraycore.NumArray'> >Out[20]:(1025, 1024) >Out[20]:<class 'numarray.numarraycore.NumArray'> > > > >Do you have any idea to help me solve this problem ? > >Thanks in advance, >cheers, >Nicolas > > > > > Nicolas: Sounds like you need to set numerix='numarray'. Try this at the beginning of your script: from matplotlib import rcParams rcParams['numerix']= 'numarray' -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/CDC R/CDC1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
The axis('scaled') was a first quick-and-dirty implementation of getting th= e=20 scale of a figure the same along both axes. When it was implemented in the= =20 previous version, John Hunter commented (correctly) that it didn't work for= =20 subplots. That is what triggered the clean implementation of axis('equal').= =20 I think axis('equal') works correctly. Except for the known problem that th= e=20 back button on the toolbar doesn't restore the previous position. I will tr= y=20 to fix this in the next week or so. I left the axis('scaled') option in, mostly as a novelty, and because I lik= e=20 it. But it is only useful if you don't have subplots. Maybe we should just= =20 get rid of it, as it is not really needed anymore. I have no idea what=20 'scaled' and 'equal' do together.=20 Regarding the autoscale_on attribute. I don't know what that was designed t= o=20 do. Can anybody explain? To summarize: 1. I will add the position to the history so that the backbutton works. 2. Let's remove the axis('scaled') option 3. I don't know how to keep axes scaled when the window size is changed.=20 Anybody know how to catch such an event? Mark On 9/8/05, Martin Richter <law...@gm...> wrote: >=20 > Hello Mark, > Hello everyone, >=20 > I wrote myself a little program which juggled five commands in all=20 > possible > orders saving each plottingresult in a png. What I could see was that=20 > (with > autoscale_on=3DFalse) the commands >=20 > imshow(something), > plot(something) > axis('scaled') > axis('equal') > axis([-2,2,-3,3])) >=20 > had to obey two rules. Then and only then the plot looked like I wanted > (i.e. it had the correct limits given by axis([...]) and a circle looked > like a circle). > (i) plot() has to be before axis([-2,2,-3,3]) > (ii) imshow() has to be before axis([-2,2,-3,3]) >=20 > I think (i) everyone knows from everyday experience with MPL. Then (ii) > doesn't suprise too much. >=20 > Remark 1) > I put axis('equal') AND axis('scaled') in, just to check out > if everything works fine. It seems to me that axis('scaled') overrules > axis('equal'). > In other words: I suppose axis('equal') doesn' set fixLimits=3DFalse. > I - preferring axis('scaled') - doesn't find this to bad. But nevertheles= s > it could be confusing to the user who prefers the other option ... on the > other hand: Propably no-one uses axis('equal') AND axis('scaled') in one > program (except me doing a 120 permutations ;-) >=20 > Remark 2) > Still: I can't become a really friend of this. If autoscale_on=3DTrue I= =20 > would > understand (i) and (ii). But it is False. When plotting doesn't autoscale > why are the limits changed? In other words: Why (i) and (ii)? You could > propably say: We already talked about the difference in > axis('equal') > axis([-2,2,-3,3]) > and > axis([-2,2,-3,3]) > axis('equal'). > But this is not true for axis('scaled'). Here the order doesn't play a=20 > role > (At least I saw this in a seperate example and I also couldn't figure out > that the order played a role for 'scaled' in my permutations - notice the > "Then and only then" before (i) and (ii)!) >=20 > That's as far as I came right now. > Bye, > Martin >=20 > PS: I don't know if this permutation-doing program is of any use to you. > That's why I haven't attached it. If you would like to have it - let me= =20 > know > ... but I wouldn't exhibit it in the Louvre if you know what I mean ;-) >=20 > -- > Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! > Satte Provisionen f=FCr GMX Partner: http://www.gmx.net/de/go/partner >
Anybody know how to update the Matplotlib distribution contained within the Enthought Python distribution? There seems to be no uninstaller for any of the packages and I'd like to update to the latest mpl. thanks, Travis -- Travis Brady td...@fa... -- http://www.fastmail.fm - mmm... Fastmail...
Hi all, I need to use contour with data for x,y and z coordinates. My data is contained in 3 numarray arrays called xi,z and rho. I can call contour with either of these 3 arrays without any problem. But when it comes to pass the 3 arrays, here's the error I get: In [19]:contour(xi,z,rho) --------------------------------------------------------------------------- exceptions.TypeError Traceback (most recent call last) /home/ngirard/.python/<console> /usr/lib/python2.4/site-packages/matplotlib/pylab.py in contour(*args, **kwargs) 1784 hold(h) 1785 try: -> 1786 ret = gca().contour(*args, **kwargs) 1787 draw_if_interactive() 1788 except: /usr/lib/python2.4/site-packages/matplotlib/axes.py in contour(self, *args, **kwargs) 1251 1252 def contour(self, *args, **kwargs): -> 1253 return self._contourHelper.contour(*args, **kwargs) 1254 contour.__doc__ = ContourSupport.contour.__doc__ 1255 /usr/lib/python2.4/site-packages/matplotlib/contour.py in contour(self, *args, **kwargs) 675 tlinewidths = [(w,) for w in linewidths] 676 --> 677 C = _contour.Cntr(x, y, z.filled(), z.mask()) 678 for level, color, width in zip(lev, tcolors, tlinewidths): 679 nlist = C.trace(level, points = 1) TypeError: Arguments x, y, z, (optional) mask must be arrays. I really don't understand where the problem is. All arrays are of the same nature: In [20]:for a in [xi,z,rho]: .20.: shape(a) .20.: type(a) .20.: Out[20]:(1025, 1024) Out[20]:<class 'numarray.numarraycore.NumArray'> Out[20]:(1025, 1024) Out[20]:<class 'numarray.numarraycore.NumArray'> Out[20]:(1025, 1024) Out[20]:<class 'numarray.numarraycore.NumArray'> Do you have any idea to help me solve this problem ? Thanks in advance, cheers, Nicolas
Message> For importing External Method in Zope, what is the module to=20 import? Create a file (e.g. mpl.py) in INSTANCEHOME\Extensions. ------ mpl.py: --------------------- from pylab import * from os import * from StringIO import StringIO from PIL import Image as PILImage from matplotlib.backends.backend_agg import FigureCanvasAgg def chart(self): clf() dpi=3D72 width=3D400 height=3D300 fig=3Dfigure(dpi, figsize=3D(width/dpi, height/dpi)) #ax=3Dsubplot(111) x=3Darange(0, 2*pi+0.1, 0.1) sine=3Dplot(x, sin(x)) legend(sine, "y=3Dsin x", "upper right") xlabel('x') ylabel('y=3Dsin x') grid(True) canvas =3D FigureCanvasAgg(fig) canvas.draw() size =3D canvas.get_width_height() buf=3Dcanvas.tostring_rgb() im=3DPILImage.fromstring('RGB', size, buf, 'raw', 'RGB', 0, 1) imgdata=3DStringIO() im.save(imgdata, 'PNG') self.REQUEST.RESPONSE.setHeader('Pragma', 'no-cache') self.REQUEST.RESPONSE.setHeader('Content-Type', 'image/png') return imgdata.getvalue() ------------------------------------------- Then create an external method in ZMI (e.g. Id -> mplchart, module name = ->=20 mpl, function name -> chart). > matplotlib or pylab Do you also have to import numeric python first? If you import pylab, then there is no need to import Numeric. > I need a real world example not a 'foo.py' module. See above. Regards, Sascha=20
On 9/8/05, Martin Richter <law...@gm...> wrote: > Remark 2) > Still: I can't become a really friend of this. If autoscale_on=3DTrue I w= ould > understand (i) and (ii). But it is False. When plotting doesn't autoscale > why are the limits changed? In other words: Why (i) and (ii)? You could > propably say: We already talked about the difference in Hello, I agree that autoscaling combined with e.g. axis('scaled') is really broken= ...=20 my worst annoyance is how the figure size is changed when I do axis('scaled') and use the zoom to rect mode, e.g. from pylab import * im=3D3 ; jm=3D4 [y,x] =3D meshgrid(arange(0.5,jm+0.5), arange(0.5,im+0.5)) h =3D sqrt(x**2 + y**2) pcolor(x,y,h) axis([0,im,0,jm]) axis('scaled') hsv()=20 show() =20 then zoom to rect and pick a very "wide" rectangle - figure changes size, now zooming to a tall rectangle will make the figure size thin and tall instead. clicking home restores the axis limits, but the weird figure size remains... (I use cvs matplotlib) humble suggestion for developers: using the right button to zoom out to a rectangle is not intuitive - I would much prefer if a single right click in the figure in this mode just took me back to the previous axis limits. and if axis('scaled') is on, it should preserve the figure aspect ratio no matter what happen - window resize, zooming in/out, whatever... otherwise, matplotlib is really improving! good job. the only features I miss are a pcolor and quiver capable of doing 500x500 data as fast as pygist :) for those hacking on the colorbar: the scipy xplt colorbar is nice. it may be possible to use some of the scaling algs. from that one. (see http://www.scipy.org/cvs/viewcvs/map?rmurl=3Dhttp%3A//scipy.net/cgi-bin/vie= wcvsx.cgi/scipy1/xplt/colorbar.py%3Frev%3D1.7%26content-type%3Dtext/vnd.vie= wcvs-markup) sincerely, Helge
I am a new Zope user and am trying to use matplotlib in a Zope application and need some guidance on how to do so. From a previous post in February 2005 (2-17-05), someone had a similar problem. From the archives, I'm not quite sure it was solved. This is the only related answer I found. From: Yves Moisan <ymoisan@gr...> <http://images.sourceforge.net/images/msg.gif> Matplotlib in a Zope and postgreSQL context 2005年04月29日 09:16 1) Is there a way people know of integrating Matplotlib into Zope ? I had to fight with the registry (yes, a windows box for now) to get matplotlib to install on the right Python (Zope"s, not the system Python) but more importantly I am using an external method to gain access to matplotlib via Zope. It works, but it"s clumsy and I suspect loading up pylab could be quicker if I could use Scripts (Python) objects in Zope. For importing External Method in Zope, what is the module to import? matplotlib or pylab Do you also have to import numeric python first? What would the functions be in the External Method import? (example: plot, arange, xlabel, etc.???) The other method listed was to install in the right Python (Zope's) by fighting with the windows registry. How is this actually done from someone with less computer programming knowledge? Is matplotlib installed in the python directory of the main Zope directory or the Zope Instance directory? I copied the matplotlib directory from my python directory (not Zope) to both the Zope directory (...\lib\python\) and Zope Instance directory (...\Extensions\) in the hope one would work. Error Type: ImportError Error Value: import of "pylab" is unauthorized How do I get security clearance for matplotlib? The information from Zope isn't as detailed as I would need. I need a real world example not a 'foo.py' module. Thank you. Dave
On Sep 8, 2005, at 8:46 AM, John Hunter wrote: > Kevin, Do you think it would be possible to make the BUILD_WXAGG logic > a little smarter so that it doesn't kill the build process? Or > perhaps set BUILD_WXAGG to False by default. I will review buildext.py and see if I can add a check for the presence of `wxPython.h'. For now, you should probably set BUILD_WXAGG to False by default. Maybe I should get this Kevin guy to help ;-) > I'm afraid this one will bite a lot of people who have wxpython > installed > but not the devel headers (as noted in previous discussions, the > debian devel > packages appear broken with respect to wxPython.h). I'm working with Ron Lee to get that fixed. It looks like it may be an upstream issue, in that the wxPython distutils script doesn't even try to install the headers. It probably won't be a hard fix, once I've made sure I understand the problem. Ken
On 2005年9月07日, Eric Firing apparently wrote: > So, the big question is: is it OK, or at least potentially > OK, to change the pylab API for contour and contourf so > that they return a single object instead of a tuple? This breaks the matlab analogy. I do not care about that myself, but people coming from matlab might. Maybe the right way to go is to provide an extended contourgroup object http://www.mathworks.com/access/helpdesk/help/techdoc/ref/contourgroupproperties.html and treat contour and contourf as convenience functions that continue to work as they do. fwiw, Alan Isaac
>>>>> "Noel" == Noel O'Boyle <no...@ca...> writes: Noel> (1) If I don't compile GTK, please don't make it the Noel> default. Yes, this is a common annoyance that needs to be fixed. Noel> (3) If I need to edit matplotlibrc, please include the list Noel> of possible options beside each of the relevant lines. I had Noel> to look up the correct spelling for TkAgg in the source (the Noel> User Guide variously refers to tkagg, Tkagg, TkAgg) - there Noel> is an easier way. In general we do numerix : Numeric # Numeric or numarray interactive : False # see http://matplotlib.sourceforge.net/interactive.html toolbar : toolbar2 # None | classic | toolbar2 timezone : UTC # a pytz timezone string, eg US/Central or Europe/Paris ...and see below... Noel> I appreciate all of the hard work by the matplotlib team and Noel> hope that my comments are helpful, They are certainly helpful and we'll fix these as we can. As you'll notice from the volume of the mailing lists and the number of different things matplotlib is trying to do, we have our hands pretty full, so I encourage people to chip in wherever possible. Eg, if there is a specific rc line that could be better like # the default backend; one of GTK GTKAgg GTKCairo FltkAgg QtAgg TkAgg # Agg Cairo GD GDK Paint PS SVG Template backend : GTKAgg and you can submit this fix instead, that will be most helpful. If there is a bug in the manual (tkagg, TkAgg, TKAgg), if you could download the source, edit it and submit the fixes, that would also be helpful. http://cvs.sourceforge.net/viewcvs.py/matplotlib/users_guide I realize that as a new user you often don't know where to find these things or this information, but I just want to point it out now because I encourage everyone to contribute what they can. Thanks, JDH
>>>>> "Nils" == Nils Wagner <nw...@me...> writes: Nils> Hi all, I am trying to build matplotlib from cvs on SuSE Nils> 9.1. Nils> python setup.py build results in Nils> src/_wxagg.cpp:55:34: wx/wxPython/wxPython.h: No such file Nils> or directory src/_wxagg.cpp: In member function `Py::Object Nils> _wxagg_module::convert_agg_to_wx_image(const Py::Tuple&)': Nils> src/_wxagg.cpp:105: error: `wxPyConstructObject' undeclared Nils> (first use this function) src/_wxagg.cpp:105: error: (Each Nils> undeclared identifier is reported only once for each Nils> function it appears in.) src/_wxagg.cpp: In member function Nils> `Py::Object _wxagg_module::convert_agg_to_wx_bitmap(const Nils> Py::Tuple&)': src/_wxagg.cpp:129: error: Nils> `wxPyConstructObject' undeclared (first use this function) Nils> src/_wxagg.cpp: In function `void init_wxagg()': Nils> src/_wxagg.cpp:260: error: `wxPyCoreAPI_IMPORT' undeclared Nils> (first use this function) error: command 'gcc' failed with Nils> exit status 1 Nils> Where can I find wxPython.h ? Nils, if you don't specifically want the wxagg animated blit functionality (as described here http://www.scipy.org/wikis/topical_software/Animations), you can set 'BUILD_WXAGG = 0' in setup.py. Otherwise, you'll need to get the devel headers as others have suggested. Kevin, Do you think it would be possible to make the BUILD_WXAGG logic a little smarter so that it doesn't kill the build process? Or perhaps set BUILD_WXAGG to False by default. I'm afraid this one will bite a lot of people who have wxpython installed but not the devel headers (as noted in previous discussions, the debian devel packages appear broken with respect to wxPython.h). JDH
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> So, the big question is: is it OK, or at least potentially Eric> OK, to change the pylab API for contour and contourf so that Eric> they return a single object instead of a tuple? It's fine with me. contour users are mostly power users, so they will adapt, and the functionality is still relatively new so it is not too deeply ingrained in people's apps. As I recall, I dumped most of the contour functionality into the ContourHelpers class just to clean up axes.py, which was beginning to be dominated by all the contour code. I think the idea of having a single object that controls all the contour functionality is a good one, because it is easier to extend w/o breaking argument passing symantics. In general, I think this would be a good idiom for all plot objects (LinePlot, ScatterPlot, ContourPlot, ImagePlot, etc...) FYI, I applied you in/out ticks patch to CVS a couple of days ago. JDH
Hello Mark, Hello everyone, I wrote myself a little program which juggled five commands in all possible orders saving each plottingresult in a png. What I could see was that (with autoscale_on=False) the commands imshow(something), plot(something) axis('scaled') axis('equal') axis([-2,2,-3,3])) had to obey two rules. Then and only then the plot looked like I wanted (i.e. it had the correct limits given by axis([...]) and a circle looked like a circle). (i) plot() has to be before axis([-2,2,-3,3]) (ii) imshow() has to be before axis([-2,2,-3,3]) I think (i) everyone knows from everyday experience with MPL. Then (ii) doesn't suprise too much. Remark 1) I put axis('equal') AND axis('scaled') in, just to check out if everything works fine. It seems to me that axis('scaled') overrules axis('equal'). In other words: I suppose axis('equal') doesn' set fixLimits=False. I - preferring axis('scaled') - doesn't find this to bad. But nevertheless it could be confusing to the user who prefers the other option ... on the other hand: Propably no-one uses axis('equal') AND axis('scaled') in one program (except me doing a 120 permutations ;-) Remark 2) Still: I can't become a really friend of this. If autoscale_on=True I would understand (i) and (ii). But it is False. When plotting doesn't autoscale why are the limits changed? In other words: Why (i) and (ii)? You could propably say: We already talked about the difference in axis('equal') axis([-2,2,-3,3]) and axis([-2,2,-3,3]) axis('equal'). But this is not true for axis('scaled'). Here the order doesn't play a role (At least I saw this in a seperate example and I also couldn't figure out that the order played a role for 'scaled' in my permutations - notice the "Then and only then" before (i) and (ii)!) That's as far as I came right now. Bye, Martin PS: I don't know if this permutation-doing program is of any use to you. That's why I haven't attached it. If you would like to have it - let me know ... but I wouldn't exhibit it in the Louvre if you know what I mean ;-) -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
Nils Wagner wrote: >>>Unfortunately, SuSE 9.1 comes without python-wxGTK-devel. >>>Which rpm's (from wxpython.org) are necessary and can be used with SuSE >>>9.1 ? >>> >> >>On 9.2 I'm using those: >> >>wxPython2.6-gtk2-unicode-2.6.1.0-1_py2.3 >>wxPython2.6-devel-gtk2-unicode-2.6.1.0-1_py2.3 >>wxPython-common-gtk2-unicode-2.6.0.1-1_py2.3 >> > > Sorry, I cannot find SuSE specific rpm's but only rpm's for Fedora, > Mandrake and Red Hat. > http://www.wxpython.org/download.php > There aren't any for SuSE, I'm using the RH9 ones. Christian
Hi Well I'm running a 2.6.11 testing kernel (due to some hardware problems under 2.6.8) but I fetch all my software (via apt-get) from the stable archives. I'm no Debian expert but I know that apt-get and dpkg perform good dependency checking when you install a .deb and should tell you if some required packages are too old. I had no problems with the two packages and my mpl is running fine. Note that I installed libpixman1_0.1.5-1_i386.deb libcairo1_0.4.0-1_i386.deb but I guess that the newer versions now available should also do the job. cheers, steve Noel O'Boyle wrote: > Thanks Steve, > I prefer to use .debs where possible. Is it risky to use packages from > unstable? I don't want to return to an rpm nightmare. > > Regards, > Noel > > On Thu, 2005年09月08日 at 11:19 +0200, Steve Schmerler wrote: > >>Noel O'Boyle wrote: >> >>>Is the debian package for matplotlib broken?? >>> >>>I found the following error when trying to install the debian package >>>for matplotlib as per the instructions at the bottom of >>>http://matplotlib.sourceforge.net/installing.html. >>> >>>apt-get install python-matplotlib python-matplotlib-doc >>>"The following packages have unmet dependencies: >>> python-matplotlib: Depends: python2.3-matplotlib (= 0.82-1) but it is >>>not going to be installed >>>E: Broken packages" >>> >>>I then tried apt-get install python2.3-matplotlib: >>>"The following packages have unmet dependencies: >>> python2.3-matplotlib: Depends: libcairo1 but it is not installable >>>E: Broken packages" >>> >>>I then tried apt-get install libcairo1: >>>"Package libcairo1 is not available, but is referred to by another >>>package. >>>This may mean that the package is missing, has been obsoleted, or >>>is only available from another source >>>E: Package libcairo1 has no installation candidate" >>> >>>Regards, >>>Noel >>> >>> >> >> >>Hi >> >>Seems that you have compiled mpl yourself by now. Anyway if you (or >>others) are still interested in installing the .debs from >>http://anakonda.altervista.org: >> >>I had to download and install libpixman1*.deb and libcairo1*.deb from >>debian.org (apt-get didn't find any of these since I'm running a sarge >>stable). Meanwhile there is a >>libcairo2_1.0.0-2_i386.deb in unstable and a ibpixman1_0.1.6-1_i386.deb >>in testing. >> >>After installing these I could do >> >>apt-get install python2.3-matplotlib python-matplotlib-data >>python-matplotlib-doc >> >>cheers, >>steve > >
Nils Wagner wrote: > Christian Kristukat wrote: > >>Nils Wagner wrote: >> >>>Hi all, >>> >>>I am trying to build matplotlib from cvs on SuSE 9.1. >>> >>>python setup.py build results in >>> >>>src/_wxagg.cpp:55:34: wx/wxPython/wxPython.h: No such file or directory >>>src/_wxagg.cpp: In member function `Py::Object >>>_wxagg_module::convert_agg_to_wx_image(const Py::Tuple&)': >>>src/_wxagg.cpp:105: error: `wxPyConstructObject' undeclared (first use >>>this function) >>>src/_wxagg.cpp:105: error: (Each undeclared identifier is reported only >>>once for each function it appears in.) >>>src/_wxagg.cpp: In member function `Py::Object >>>_wxagg_module::convert_agg_to_wx_bitmap(const Py::Tuple&)': >>>src/_wxagg.cpp:129: error: `wxPyConstructObject' undeclared (first use >>>this function) >>>src/_wxagg.cpp: In function `void init_wxagg()': >>>src/_wxagg.cpp:260: error: `wxPyCoreAPI_IMPORT' undeclared (first use >>>this function) >>>error: command 'gcc' failed with exit status 1 >>> >>>Where can I find wxPython.h ? >>> >>>cvs/matplotlib> rpm -qi python-wxGTK >> >>Have you installed python-wxGTK-devel as well? The include files >>should be there. Btw. the rpm packages from wxpython.org work without >>problems on SuSE and are more recent than those shipped. >> > > Unfortunately, SuSE 9.1 comes without python-wxGTK-devel. > Which rpm's (from wxpython.org) are necessary and can be used with SuSE > 9.1 ? > On 9.2 I'm using those: wxPython2.6-gtk2-unicode-2.6.1.0-1_py2.3 wxPython2.6-devel-gtk2-unicode-2.6.1.0-1_py2.3 wxPython-common-gtk2-unicode-2.6.0.1-1_py2.3 Christian
> On my linux box (Debian Sarge, Python 2.3, Matplotlib 0.82) the first > example, text(0.5, 0.5, u'\u03bb'), correctly shows a lambda, but the > second, text(0.5, 0.5, u'\u03bb'.encode('utf8')), only shows 2 small > boxes. Perhaps you do not have all the required fonts installed? I am not sure what fonts need to be installed. Actually I thought Matplotlib brings its own fonts... -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++
On my linux box (Debian Sarge, Python 2.3, Matplotlib 0.82) the first example, text(0.5, 0.5, u'\u03bb'), correctly shows a lambda, but the second, text(0.5, 0.5, u'\u03bb'.encode('utf8')), only shows 2 small boxes. Perhaps you do not have all the required fonts installed?
I am using the AGG backend and I am having issues with displaying unicode characters in MPL on a Linux box. Instead of the actual character I see only a placeholder/square symbol. E.g. the following command text(0.5, 0.5, u'\u03bb') correctly shows the small greek letter lambda on my windows machine, but on Linux, I get only a placeholder. I also tried text(0.5, 0.5, u'\u03bb'.encode('utf8')) and some other encodings but the result is the same. The python default encoding is UTF-8 on both systems. Is this maybe due to the font not being able to display this character (not sure whether different fonts are used on different OSs) or am I making some encoding mistake? Thanks in advance, Sascha -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++
Hello everyone, Arnd Baecker and I tried a while to enlarge the thickness of tick-lines. One of our presumptions was: ax = gca() xticks = ax.xaxis.get_ticklines() setp(xticks, linewidth= 4) This was not working. But we finally found a way to do so. To do the desired enlargement we had to edit the 'lines.py'-file. Because of the ticks also just being lines we added something to the methods _draw_tickleft(self, renderer, gc, xt, yt) _draw_tickright(self, renderer, gc, xt, yt) _draw_tickup(self, renderer, gc, xt, yt) _draw_tickdown(self, renderer, gc, xt, yt). Right after each offset = renderer.points_to_pixels(self._markersize) (which as far as we know sets the lenght of the ticks with help of the rc-file via some minor detours) we wrote a gc.set_linewidth(self._linewidth). Now the ax = gca() xticks = ax.xaxis.get_ticklines() setp(xticks, linewidth= 4) did work well! Now there are three more things to ask: a) Is there any drawback? We just used the self._linewidth without really knowing what it was for. Could it be that some user sets a parameter somewhere to change some other linewidth and changes the tickwidth "en passant"? b) In behalf of unification it would possibly be better to add this option to the .matplotlibrc-file in the neighbourhood of tick.major.size : 4 # major tick size in points. (As far as I can see this means changeing the Class Tick's __init__ placed in axis.py a little bit.) c) Now it is possible to change 'lw'. Should it also be possible to change 'color', 'linestyle'? Bye, Martin -- GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
Dear all, I have just succeeded in compiling and installing matplotlib on Debian Sarge. I look forward to many hours of happy graphing, etc. However, I think that there are a few things which could be done to make the whole procedure less painful for users. I compiled with the Tk backend. But when I tried to import pylab, it kept looking for the GTK backend. After several recompilations, I realised that matplotlibrc still thought the default backend was GTKAgg. I changed this to TKAgg and all was fine. Problems/Solutions: (1) If I don't compile GTK, please don't make it the default. Or, at least, in the installation procedure please tell me to change the default backend in matplotlibrc (or even, just tell me about matplotlibrc). (2) If I need to edit setup.py, please include the list of possible options beside each of the relevant lines. (3) If I need to edit matplotlibrc, please include the list of possible options beside each of the relevant lines. I had to look up the correct spelling for TkAgg in the source (the User Guide variously refers to tkagg, Tkagg, TkAgg) - there is an easier way. I appreciate all of the hard work by the matplotlib team and hope that my comments are helpful, Regards, Noel O'Boyle.
John, Jeff, As I mentioned a couple weeks ago, I found that the CVS change to colorbar breaks contourf if called with explicit colors rather than a colormap. I think this is just a symptom of deeper problems in contour.py, so I have been trying to improve the whole system before dealing with the specific colorbar problem. I have found it very difficult to keep track of what is going on in the present system, particularly with respect to the "mappable" object that gets tacked onto the list of collections that contour and contourf return. I think the root of the problem is the tension between OO design and the non-OO matlab compatibility of the present contour and contourf functions, combined with the minimally OO construction of the ContourHelper class (which is mostly a package of functions). Now, the functions return (levs, collections), where levs is the list of contour levels and collections is a silent_list of collections with an attached ContourMappable object. What I want to do instead is return a single object that includes everything useful; it inherits from ScalarMappable (like collections do), it includes the levels, the list of collections, and all the various relevant attributes of the contour plot. Passing this object to a colorbar function or a clabel function then makes it much easier for these functions to do the right thing--they get the necessary information in a single straightforward package. So, the big question is: is it OK, or at least potentially OK, to change the pylab API for contour and contourf so that they return a single object instead of a tuple? I am part-way there, and I think going the rest of the way would be good for the long-term usability and maintainability of mpl. But I don't want to go the rest of the way, which will affect many files and also break some users' programs, if this is judged to be too radical a change, or otherwise undesirable. Eric