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
(3) |
2
(21) |
3
(16) |
4
(4) |
5
(7) |
6
(1) |
7
(2) |
8
(12) |
9
(23) |
10
(6) |
11
(2) |
12
(1) |
13
(1) |
14
(4) |
15
(14) |
16
(7) |
17
(15) |
18
(12) |
19
(5) |
20
|
21
(1) |
22
(7) |
23
(7) |
24
(6) |
25
(5) |
26
(9) |
27
(6) |
28
(4) |
29
(4) |
30
(27) |
|
|
|
>>>>> "Christian" == Christian David Ott <chr...@gm...> writes: Christian> Hi, sorry about my previous e-mail. I have now tried Christian> the same with 0.85. The tick marks are now by default Yep, the axisbelow property was just added in 0.85 and this controls whether the ticks and grid lines are drawn above or below your data lines. Christian> on top of the data graphs while the axes lines (please Christian> correct my vocabulary usage here, axes lines = figure Christian> frame?) are still below. I see the source of our previous confusion -- matplotlib has a figure patch and an axes patch. The figure patch controls the backgroud of the entire figure canvas and the frame of this borders your window or paper. The axes patch is the thing surrounding the subplot/axes (eg the white area where your data are). I think in your previous emails when you referred to the "figure frame" you meant the axes frame. In which case you would use subplot(111, frameon=False) Christian> To get the figure frame drawn on top of everything, one Christian> has to modify axes.draw. Namely, one adds to Christian> these 4 lines: Christian> if self.axison: if self._frameon: Christian> self.axesPatch.set_fill(False) Christian> self.axesPatch.draw(renderer) So basically, you want a second draw of the axespatch edge over the ticks. Could you post a script w/o these changes that shows the undesirable effect, so I can see better what the problem is. I worry that doing two draws of the axes patch, one w/ the fill first and one w/o the fill later will screw up the alpha channel of the edgecolor of the axes patch. Albeit a corner case. JDH
Hi, sorry about my previous e-mail. I have now tried the same with 0.85. The tick marks are now by default on top of the data graphs while the axes lines (please correct my vocabulary usage here, axes lines =3D figure frame?) are still below. To get the figure frame drawn on top of everything, one has to modify axes.draw. Namely, one adds to if not self._axisbelow: if self.axison and not inframe: self.xaxis.draw(renderer) self.yaxis.draw(renderer) these 4 lines: if self.axison: if self._frameon: self.axesPatch.set_fill(False) self.axesPatch.draw(renderer) . Also, one has to set gca.set_axisbelow(False) for the if block to be executed. The additional code draws another figure frame, this time without filling, on top of the previous one and the data graphs. - Christian On 11/19/05, Christian David Ott wrote: > Hi, > > using the PS Backend and matplotlib 0.82 with python 2.3.5 I have the > problem that my graphs typically show up on top of the axes lines (the > figure frame) and tick marks. However, for a journal quality figure, I > need the axes and the tick marks to be on top of the graph(s). > > I looked through the archives and found below e-mail. Has there been > any progress in fixing this? Has Michael Brady submitted a patch? > > Thanks. > > - Christian > >
John Hunter wrote: >>>>>>"Christian" == Christian Kristukat <ck...@ho...> writes: > > > Christian> I tried that before. It gives a filled white frame > Christian> without border line. I checked that using skencil and > Christian> pstoedit to convert into skencil's own format. > Christian> Btw. I'm using a smaller figure size than the default > Christian> and the eps always contains a small polygon with 4 > Christian> nodes down at the left bottom of larger page which is > Christian> about DIN A4/US Letter which makes the bounding box > Christian> unnecessary big. > > You might want to try again. This is pretty much guaranteed to work. > The Figure.draw method in figure.py reads: > > if self.frameon: self.figurePatch.draw(renderer) > I just checked by inserting a print statement, that self.frameon is True 4 times during one run of simple_plot.py with figure(frameon=False) Christian
John Hunter wrote: >>>>>>"Christian" == Christian Kristukat <ck...@ho...> writes: > > > Christian> I tried that before. It gives a filled white frame > Christian> without border line. I checked that using skencil and > Christian> pstoedit to convert into skencil's own format. > Christian> Btw. I'm using a smaller figure size than the default > Christian> and the eps always contains a small polygon with 4 > Christian> nodes down at the left bottom of larger page which is > Christian> about DIN A4/US Letter which makes the bounding box > Christian> unnecessary big. > > You might want to try again. This is pretty much guaranteed to work. > The Figure.draw method in figure.py reads: > > if self.frameon: self.figurePatch.draw(renderer) > > I don't see how the patch can be drawn if frameon is false... Maybe we're not talking about the same frame? I attached a bitmap created with skencil after having converted the eps with pstoedit. I coloured the frame green. Christian
Hi, using the PS Backend and matplotlib 0.82 with python 2.3.5 I have the problem that my graphs typically show up on top of the axes lines (the figure frame) and tick marks. However, for a journal quality figure, I need the axes and the tick marks to be on top of the graph(s). I looked through the archives and found below e-mail. Has there been any progress in fixing this? Has Michael Brady submitted a patch? Thanks. - Christian ***************************************************************** >>>>> "Michael" =3D=3D Michael Brady <mbrady@jp...> writes: Michael> I tried setting the z-order of the tick objects, but it Michael> looks to me like the ticks are hard-coded to always draw Michael> before (underneath) any lines or patches. That"s right, they are. This is a bug and not a feature :-( The ticks are drawn as part of the Axis. See matplotlib.axes.Axes.draw, eg if self.axison: self.xaxis.draw(renderer) self.yaxis.draw(renderer) The Axis instances (XAxis and YAxis) are comprised of Line2D (the ticks) and Text (the labels) instances. Michael> Is there a way to tell the Axes to draw the ticks on top Michael> of any Polygons instead of underneath? As noted above, before any of the zorder sorting is done, the xaxis and yaxis are drawn. One possible solution is to move the axis drawing commands to the end of the Axes.draw function. Off the top of my head, I don"t see any problem with this approach. Typically, you want the ticks visible. We"ve talked in the past on the dev list about the desirability in supporting ticking inside, center or outside the axes box, but it hasn"t been implemented yet. Vis-a-vis zorder sorting, a more general solution would be to have a method which extracts the Artist primitives (Line2D and Text) from the XAxis and YAxis and adds them to the sort, but I"m not sure if this is actually better. In real life, I think you always want them on top. Right? Michael> If not, it doesn"t look like it would be too hard to Michael> modify Axes.draw() to respect the z-order of ticks. I"m Michael> happy to do this, although I"m nervous that it might Michael> break stuff that assumes that ticks are always drawn Michael> before everything else. John, do you recommend that I Michael> create such a mod? Yes, if you can find something that works, and behaves sanely over the poorman"s unit tests in examples/backend_driver.py. JDH
>>>>> "Christian" == Christian Kristukat <ck...@ho...> writes: Christian> I tried that before. It gives a filled white frame Christian> without border line. I checked that using skencil and Christian> pstoedit to convert into skencil's own format. Christian> Btw. I'm using a smaller figure size than the default Christian> and the eps always contains a small polygon with 4 Christian> nodes down at the left bottom of larger page which is Christian> about DIN A4/US Letter which makes the bounding box Christian> unnecessary big. You might want to try again. This is pretty much guaranteed to work. The Figure.draw method in figure.py reads: if self.frameon: self.figurePatch.draw(renderer) I don't see how the patch can be drawn if frameon is false... JDH
>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes: Jeff> Hi: I just updated to 0.85 which appeared on sf today. I'm Jeff> getting this error using the gtk-agg backend on macos x: Jeff> Traceback (most recent call last): File Jeff> "/sw/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", Jeff> line 303, in expose_event self._render_figure(self._pixmap, Jeff> w, h) File Jeff> "/sw/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py", Jeff> line 80, in _render_figure pixbuf = Jeff> gtk.gdk.pixbuf_new_from_data( AttributeError: 'module' Jeff> object has no attribute 'pixbuf_new_from_data' Jeff> 0.84 worked fine. Do I need a newer version of pygtk? This was the start of an attempt to get rid of the gtkagg extension code and replace it with pure pygtk calls. There is an equivalent method for older version of pygtk. For now, in _backend_gtkagg.py in the _render_figure method, just uncomment #agg_to_gtk_drawable(pixmap, self.renderer._renderer, None) and comment out buf = self.buffer_rgba(0,0) ren = self.get_renderer() w = int(ren.width) h = int(ren.height) pixbuf = gtk.gdk.pixbuf_new_from_data( buf, gtk.gdk.COLORSPACE_RGB, True, 8, w, h, w*4) pixmap.draw_pixbuf(pixmap.new_gc(), pixbuf, 0, 0, 0, 0, w, h, gtk.gdk.RGB_DITHER_NONE, 0, 0) Or upgrade your pygtk (2.4 or later, me thinks) JDH
A challenge to the community! ;) Run the current cursor.py example with the TkAgg backend. (blitting should be on) i.e. python cursor.py -dTkAgg Why does the blitting not update the entire axis? Any help on this is greatly appreciated. Thanks, Charlie On 11/10/05, Charlie Moad <cw...@gm...> wrote: > So this happens with TkAgg and blitting. Here is the sample script: > > #!/usr/bin/env python > import matplotlib; matplotlib.use('TkAgg') > import pylab > from matplotlib.widgets import SpanSelector > > fig =3D pylab.figure() > ax =3D fig.add_subplot(111) > > ax.plot(pylab.rand(100)) > def onselect(vmin, vmax): > print vmin, vmax > > span =3D SpanSelector(ax, onselect, 'horizontal', useblit=3DTrue, > rectprops=3Ddict(alpha=3D0.5, facecolor=3D'red') ) > > pylab.show() > > Adjust the subplot params then you will see the distortion. With 2 > subplots the spanselector never visually appears, but the callback is > called. > > Thanks, > Charlie > > On 11/9/05, Charlie Moad <cw...@gm...> wrote: > > I will have to do more testing, but I am calling > > figure.subplots_adjust, not adjusting with the widget. This is also > > through the oo interface. I will try to write a sample script and get > > back to the list. > > > > Thanks, > > > > On 11/9/05, John Hunter <jdh...@ac...> wrote: > > > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes: > > > > > > Charlie> I guess I should have mentioned TkAgg CVS. I didn't > > > Charlie> think the problem would be specific to a backend, so I > > > Charlie> didn't try any others. Also, when I have more than one > > > Charlie> subplot, nothing is drawn period. > > > > > > tkagg works for me, as do multiple subplots. Weird. I'm using > > > examples/span_selector.py. You too? > > > > > > JDH > > > > > >
Hi: I just updated to 0.85 which appeared on sf today. I'm getting this error using the gtk-agg backend on macos x: Traceback (most recent call last): File "/sw/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line 303, in expose_event self._render_figure(self._pixmap, w, h) File "/sw/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py", line 80, in _render_figure pixbuf = gtk.gdk.pixbuf_new_from_data( AttributeError: 'module' object has no attribute 'pixbuf_new_from_data' 0.84 worked fine. Do I need a newer version of pygtk? -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
John Hunter wrote: >>>>>>"Christian" == Christian Kristukat <ck...@ho...> writes: > > > Christian> but now the frame line is back again - in white. > > Christian> Any other ideas? > > You want > > fig = figure(frameon=False) > > or for an existing fig > > fig.frameon = False I tried that before. It gives a filled white frame without border line. I checked that using skencil and pstoedit to convert into skencil's own format. Btw. I'm using a smaller figure size than the default and the eps always contains a small polygon with 4 nodes down at the left bottom of larger page which is about DIN A4/US Letter which makes the bounding box unnecessary big. Christian
>>>>> "Christian" == Christian Kristukat <ck...@ho...> writes: Christian> but now the frame line is back again - in white. Christian> Any other ideas? You want fig = figure(frameon=False) or for an existing fig fig.frameon = False JDH
John Hunter wrote: >>>>>>"Christian" == Christian Kristukat <ck...@ho...> writes: > > > Christian> Hi, I'm trying to create an eps file which does not > Christian> have a figure frame. I used figurePatch.fill = False to > Christian> prevent filling but there's still a white frame drawn > Christian> around the figure which is visible when putting it on a > Christian> coloured background. > > Christian> figurePatch.set_lw(0.0) didn't help neither. > > Christian> figure(frameon=False) seems to have no effect. > > The standard trick is to set the figure facecolor and edgecolor to be > the same. For whatever reason, a linewidth of 0 is not handled > consistently across ps drivers. > > setp(figurePatch, facecolor=somecolor, edgecolor=somecolor, linewidth=0) Indeed the frame line is not drawn in that case, but it is still beeing filled. To prevent filling I tried: f.figurePatch.fill = False setp(f.figurePatch, facecolor='black', edgecolor='black', linewidth=0) but now the frame line is back again - in white. Any other ideas? Christian
John Hunter wrote: > The standard trick is to set the figure facecolor and edgecolor to be > the same. For whatever reason, a linewidth of 0 is not handled > consistently across ps drivers. In the PostScript model (and thus also PDF), a linewidth of 0 means "1 pixel at the rendered resolution," not that the line is invisible. -- Robert Kern rob...@gm... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
>>>>> "E" == E David Huckaby <e.d...@NE...> writes: E> If the line: std::string stdtext; is changed to std::string E> stdtest = ""; E> then it seems to work fine. Hmm, that's surprising. Does the standard define what the default initialization value for std::string should be. Me thinks it would be ""; In any case, I made the change. Can't hurt. Thanks, JDH
>>>>> "Martin" == Martin Kuemmel <mku...@es...> writes: Martin> Dear all, an attempt to update from matplotlib-0.71 to Martin> matplotlib-0.84 on a solaris 5.8 (GCC-3.3.2, Python 2.4.2) Martin> machine failed. The error message is: Martin> In file included from src/_na_backend_agg.cpp:24: Martin> src/swig_runtime.h: In function `int Martin> SWIG_Python_ConvertPtr(PyObject*, void**, swig_type_info*, Martin> int)': src/swig_runtime.h:1128: error: `Py_False' Martin> undeclared (first use this function) Martin> src/swig_runtime.h:1128: error: (Each undeclared Martin> identifier is reported only once for each function it Martin> appears in.) src/swig_runtime.h: In function `PyObject* Martin> SWIG_Python_NewPointerObj(void*, swig_type_info*, int)': Martin> src/swig_runtime.h:1236: error: `Py_True' undeclared Martin> (first use this function) error: command 'gcc' failed with Martin> exit status 1 Try regenerating the SWIG headers on your local machine by installing *the most recent* version of SWIG and then running python makeswig.py before trying to build. This will regenerate the SWIG runtime. Alternatively, you could try with mpl 0.85 which has a new version of SWIG headers (built on a solaris box, coincidentally) JDH
>>>>> "Andrew" == Andrew Straw <str...@as...> writes: Andrew> You can use a combination of axes() to define where you Andrew> want the image and imshow() to define the image. Use Andrew> frame_on=False with axes(). You can pass a PIL image Andrew> directly to imshow(), and that way you won't have to use Andrew> imread, (although you'd have to use Image.open()). If your logo is a fixed size in pixels, you can also use figimage to place an unscaled image directly onto the canvas. A wiki entry on matplotlib images + PIL would be useful. JDH
>>>>> "Christian" == Christian Kristukat <ck...@ho...> writes: Christian> Hi, I'm trying to create an eps file which does not Christian> have a figure frame. I used figurePatch.fill = False to Christian> prevent filling but there's still a white frame drawn Christian> around the figure which is visible when putting it on a Christian> coloured background. Christian> figurePatch.set_lw(0.0) didn't help neither. Christian> figure(frameon=False) seems to have no effect. The standard trick is to set the figure facecolor and edgecolor to be the same. For whatever reason, a linewidth of 0 is not handled consistently across ps drivers. setp(figurePatch, facecolor=somecolor, edgecolor=somecolor, linewidth=0) should work. JDH Christian> Thank you in advance, Christian Christian> ------------------------------------------------------- Christian> This SF.Net email is sponsored by the JBoss Inc. Get Christian> Certified Today Register for a JBoss Training Course. Christian> Free Certification Exam for All Training Attendees Christian> Through End of 2005. For more info visit: Christian> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click Christian> _______________________________________________ Christian> Matplotlib-users mailing list Christian> Mat...@li... Christian> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Hi, I'm trying to create an eps file which does not have a figure frame. I used figurePatch.fill = False to prevent filling but there's still a white frame drawn around the figure which is visible when putting it on a coloured background. figurePatch.set_lw(0.0) didn't help neither. figure(frameon=False) seems to have no effect. Thank you in advance, Christian
I get a "Memory Error" when I execute the following: import numarray import pylab N = 100000 # or any large number pylab.plot( numarray.arange(N) ) pylab.show() I built using gcc 4.0.2 with matplotlib 0.85 and numarray 1.4.1 I think I tracked down the problem to the routine FT2Font::set_text() in file "ft2font.cpp" if the line: std::string stdtext; is changed to: std::string stdtext = ""; seems to fix the problem. Dave
Executing the following: import pylab, numarray N = 100000 pylab.plot( numarray(N) ) pylab.show() results in a "Memory Error". I compiled using gcc 4.0.2 with numarray 1.4.1 and matplotlib 0.85. I think I tracked down the error to the routine "FT2Font::set_text()" in "ft2font.cpp". If the line: std::string stdtext; is changed to std::string stdtest = ""; then it seems to work fine. Dave
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Thanks Todd, John,<br> <br> I don't think the building would have been a problem - it showed up on two different (winXP) machines with recently-installed pre-built binaries of all the packages. Heck maybe it would have helped - who knows...?<br> <br> The quicker fix - the numerix setting in the rc file did sort the problem. Sorry - I should have checked that already, but it hasn't seemed necessary under python2.3. Doing the reverse (setting numerix=numarray but then using Numeric) also isn't a problem under python2.4. Maybe its to do with the changes in the numarray array type that are making way for scipy core.<br> <br> Anyway, tip of the day: setting numerix=numarray is a good default.<br> <br> cheers guys<br> <br> <br> John Hunter wrote: <blockquote type="cite"> <pre wrap="">"Jon" == Jon Peirce <a class="moz-txt-link-rfc2396E" href="mailto:Jon...@no..."><Jon...@no...></a> writes: </pre> </blockquote> <blockquote cite="mid...@pe..." type="cite"> <pre wrap=""><!----> Jon> 0-10 #-------- import numarray, pylab Jon> pylab.plot(numarray.arange(10)) pylab.show() #-------- Jon> It does on my system with old python2.3.3 (Numeric or Jon> numarray) and with python2.4.1 using Numeric. With the Jon> specific combo of py2.4.1 and numarray it gives a flat line Jon> of zeros. The problem is the same on all versions of pylab Jon> i've tried including the latest 0.85 Though this shouldn't matter and I think Todd's suggestion is more likely to help, you need to also make sure your numerix setting is numarray. You can set this in your rc file and verify the setting by running your script in verbose mode > python myscript.py --verbose-helpful JDH</pre> </blockquote> <br> <blockquote cite="mid...@pe..." type="cite"> <pre wrap=""><blockquote type="cite">I just tried this with numarray-1.4.1 and CVS, Python-2.4.1 and Python-2.3.3, and pylab CVS, all on Fedora Core 4 on x86_64 and it worked as expected. Sometimes a quick and dirty fix is to completely wipe your existing installations from site-packages and then carefully rebuild and reinstall. By "carefully rebuilding" I mean deleting any build directories you have lying around. I realize it is shot-gunning... sometimes that's enough. Regards, Todd </blockquote> </pre> </blockquote> <br> <pre class="moz-signature" cols="72">-- Jon Peirce Nottingham University +44 (0)115 8467176 (tel) +44 (0)115 9515324 (fax) <a class="moz-txt-link-freetext" href="http://www.peirce.org.uk/">http://www.peirce.org.uk/</a></pre> </body> <br/> <p> This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. </p> </html>
>>>>> "Samuel" == Samuel GARCIA <sg...@ol...> writes: Samuel> Yes I understand the solution I try it, it work but the Samuel> problem comes with when I try text() function of pylab Samuel> that does'nt exist in matplotlib. I think it's to much With very few exceptions, all pylab functions are thin wrappers around matplotlib functions. Eg, take a look at the text function in matplotlib/pylab.py def text(*args, **kwargs): ret = gca().text(*args, **kwargs) draw_if_interactive() return ret Since gca() is returning the current axes, you can see that "text" is actually an Axes method - http://matplotlib.sourceforge.net/matplotlib.axes.html#Axes-text . Samuel> work for me to rewrite functions that are in pylab and not Samuel> in matplotlib. I am a newbie and I don't care to not Samuel> write programs in pure pytonic style. from pylab import * Samuel> is good for me. If you want to use pylab to manage your figure windows, but modify the GUI somewhat, you can do this by accessing the figure manager widgets. Specifically, the manager has attributes manager.window : the gtk window manager.vbox : a gtk.VBox, holds the canvas and toolbar manager.canvas : the figure canvas, a gtk.DrawingArea manager.toolbar : holds the gtk.Toolbar Below is an example. Have fun! JDH """ An example of how to use pylab to manage your figure windows, but modify the GUI by accessing the underlying gtk widgets """ import matplotlib matplotlib.use('GTKAgg') from pylab import get_current_fig_manager, subplot, plot, legend, connect, show ax = subplot(111) plot([1,2,3], 'ro-', label='easy as 1 2 3') plot([1,4,9], 'gs--', label='easy as 1 2 3 squared') legend() manager = get_current_fig_manager() # you can also access the window or vbox attributes this way toolbar = manager.toolbar # now let's add a button to the toolbar import gtk next = 8; #where to insert this in the mpl toolbar button = gtk.Button('Click me') button.show() def clicked(button): print 'hi mom' button.connect('clicked', clicked) toolitem = gtk.ToolItem() toolitem.show() toolitem.set_tooltip( toolbar.tooltips, 'Click me for fun and profit') toolitem.add(button) toolbar.insert(toolitem, next); next +=1 # now let's add a widget to the vbox label = gtk.Label() label.set_markup('Drag mouse over axes for position') label.show() vbox = manager.vbox vbox.pack_start(label, False, False) vbox.reorder_child(manager.toolbar, -1) def update(event): if event.xdata is None: label.set_markup('Drag mouse over axes for position') else: label.set_markup('<span color="#ef0000">x,y=(%f, %f)</span>'%(event.xdata, event.ydata)) connect('motion_notify_event', update) show()
>>>>> "Jon" == Jon Peirce <Jon...@no...> writes: Jon> 0-10 #-------- import numarray, pylab Jon> pylab.plot(numarray.arange(10)) pylab.show() #-------- Jon> It does on my system with old python2.3.3 (Numeric or Jon> numarray) and with python2.4.1 using Numeric. With the Jon> specific combo of py2.4.1 and numarray it gives a flat line Jon> of zeros. The problem is the same on all versions of pylab Jon> i've tried including the latest 0.85 Though this shouldn't matter and I think Todd's suggestion is more likely to help, you need to also make sure your numerix setting is numarray. You can set this in your rc file and verify the setting by running your script in verbose mode > python myscript.py --verbose-helpful JDH
Jon Peirce wrote: > Hi there. Has anyone tried using pylab with python24 and numarray > (1.4.1)? > > The following should obviously plot a line 0-10 > #-------- > import numarray, pylab > > pylab.plot(numarray.arange(10)) > pylab.show() > #-------- > > It does on my system with old python2.3.3 (Numeric or numarray) and > with python2.4.1 using Numeric. With the specific combo of py2.4.1 and > numarray it gives a flat line of zeros. The problem is the same on > all versions of pylab i've tried including the latest 0.85 > > anyone got a fix? I just tried this with numarray-1.4.1 and CVS, Python-2.4.1 and Python-2.3.3, and pylab CVS, all on Fedora Core 4 on x86_64 and it worked as expected. Sometimes a quick and dirty fix is to completely wipe your existing installations from site-packages and then carefully rebuild and reinstall. By "carefully rebuilding" I mean deleting any build directories you have lying around. I realize it is shot-gunning... sometimes that's enough. Regards, Todd
replying to myself, but I found a workaround int = ax.yaxis.get_view_interval() ymin,ymax = int.get_bounds() if ymax - ymin < 0.01: ymin = ymin - 0.005 ymax = ymax + 0.005 int.set_bounds(ymin,ymax) Is there a better way?