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
(23) |
3
(17) |
4
(14) |
5
(12) |
6
(2) |
7
(3) |
8
(7) |
9
(13) |
10
(19) |
11
(24) |
12
(28) |
13
(9) |
14
(5) |
15
(7) |
16
(17) |
17
(17) |
18
(15) |
19
(6) |
20
|
21
(7) |
22
(20) |
23
(6) |
24
(4) |
25
(5) |
26
(11) |
27
(1) |
28
(2) |
29
(14) |
30
(7) |
|
|
|
|
Greetings. I am making some contour plots and in my field for this particular value, there are two widely used units. As such, it is very useful to have both units listed on the colorbar. To clarify: the colorbar's normal ticks would be facing to the right and labeled with Unit Type 1, which was the units that the data were in when they were plotted. Unit Type 2 is simply a factor of X different than unit type two. It would be nice if I could add a second set of ticks to the color bar using a different locator and have them face left. Is this possible? Is there another way to display two values for each tick such that the colorbar shows both units? Thanks. -dw
Hello, I am running Python 2.5.2 on win xp sp3 on an Intel Core2 Duo. After installation of matplotlib-1.0.0.win32-py2.5.exe I get a Windows crash on importing pylab. import pylab -> An unhandled win32 exception occured in python.exe [5048] import matplotlib works I did not add anything to the matplotlibrc. I uninstalled matplotlib and re-installed with the same problem. matplotlib-0.99.3.win32-py2.5.exe gives me the same problem. The older version I had installed before (forgot which one) worked fine. Dan
Dear all, I must be doing something wrong, but it seems like the backgroundcolor statement for text just stopped working. I am using matplotlib 1.0.0 with MacOSX as backend on two different machines. If I run ipython -pylab text(0,0,'Kalle',backgroundcolor='0.6') I get this result:
I noticed that in another post and did try that but the behavior was the same. martin. On Fri, Nov 12, 2010 at 9:14 AM, Ryan May <rm...@gm...> wrote: > On Thu, Nov 11, 2010 at 9:41 PM, Martin Bures <nee...@gm...> > wrote: > > I am having a little issue with the matplotlib.widgets RectangleSelector. > > The behavior is that the first time I try to select a region, no > rectangle > > draws. All subsequent uses work correctly. > > > > Here is how I am calling: > > if self.zoomMode: > > if self.canvas.widgetlock.locked(): > > self.canvas.widgetlock.release( self.lasso ) > > > > RectangleSelector( self.ax, > > self._zoom_callback, > > drawtype='box', > > minspanx=5, minspany=5, > > spancoords='pixels' ) > > else: > > if self.canvas.widgetlock.locked(): > > self.canvas.widgetlock.release( self.lasso ) > > > > if event.inaxes is None: return > > > > self.lasso = Lasso( event.inaxes, > > ( event.xdata, event.ydata ), > > self._selection_callback ) > > self.canvas.widgetlock( self.lasso ) > > > > This could be another instance of a problem resulting from our changes > to how references are taken for callbacks. Try saving the > RectangleSelector you create (I'm just guessing here): > > self.rs = RectangleSelector( self.ax, > self._zoom_callback, > drawtype='box', > minspanx=5, minspany=5, > spancoords='pixels' ) > > Ryan > > -- > Ryan May > Graduate Research Assistant > School of Meteorology > University of Oklahoma >
> From: Thøger Emil Juul Thorsen [mailto:th...@fy...] > Sent: Tuesday, November 09, 2010 11:10 > > I'm trying to do a fill-between part of a spectrum and its continuum > value. I would strongly prefer the drawstyle to be steps, since each > data point represents a bin (or pixel, to be precise). > > Attached is a picture illustrating my problem. > > Isn't it possible to fill between my step graph and the hline? I haven't found that capability built-in, but you could do it if you construct the steps yourself. In lines.py in the matplotlib source, look at the _draw_steps_pre and similar methods of the Line2D class to see how the coordinates of the stepped path are constructed. You could then pass those coordinates to fill_between.
On Fri, Nov 12, 2010 at 8:40 AM, Benjamin Root <ben...@ou...> wrote: > On Fri, Nov 12, 2010 at 5:11 AM, Guy Griffiths <guy...@re...> > wrote: >> >> Hi, >> >> I've been using matplotlib for a while for plotting scientific data, and >> recently upgraded from version 0.99.1.1 to 1.0.0. Primarily I use pcolor >> to >> produce plots of concentration in 2D space. I use reasonably fine meshes, >> and >> in v0.99.1.1 the output looked great. >> >> In v1.0.0, all of my plots (using the same code) have faint gridlines >> visible. >> Since the mesh I am using is quite fine, this makes the plots look >> terrible >> (i.e. more gridlines than actual data). This seems to be controlled by >> the >> "edgecolors" keyword, but even when set to 'none' they are still there. >> Is >> there any way to remove them completely without reverting back to 0.99.1.1 >> (which I'd prefer not to do, since some of the API changes are really >> useful >> for creating very polished graphs suitable for publication)? >> >> imshow seems to have closer results to what I want (i.e. no gridlines), >> but >> with imshow, the axes denote the pixel position, and there is no option to >> display on polar axes (which is essential). >> >> Any help would be much appreciated. >> >> Regards, >> >> Guy Griffiths >> > > Guy, I have noticed something similar a few months ago with pcolor, but I am > not certain if it is the same problem as yours. First, which backend are > you using? Second, are you seeing the grid lines in both the figure window > and the saved output? Also, what format are you saving your output to? > Lastly, which pcolor function are you using (pcolor(), pcolormesh(), > pcolorfast())? > > If you could include a screenshot or the saved file, I could see if it is > similar to my problem. Yeah, I had noticed a problem with pcolor too. You can see the problem I've been seeing here: http://matplotlib.sourceforge.net/examples/pylab_examples/pcolor_demo.html Calling pcolor with antialiased=False removes the lines, but that's just a workaround, not a solution. I'm not really sure where to start to track this down, so if anyone has a suggestion, I'm all ears. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
On Sun, Nov 7, 2010 at 9:40 AM, LB <bra...@gm...> wrote: > Hi, > > I'm trying to draw a bar chart according to > http://matplotlib.sourceforge.net/examples/api/barchart_demo.html, and I'm > having to difficulties : > > - when the first bar has a zero height, it is no taken into account during > the axis limits calculation and is not visible > > - texts objects can exceed chart area and collide with the chart title. > > Is there a way to calculate the axis limit to use to include all texts > objects into the chart area ? > > Here is the code I used : > > [code] > #!/usr/bin/env python > > import numpy as np > import matplotlib.pyplot as plt > > menMeans = [ 0. , 998. , 1210. , 1449. , > 1496. , 1493. , 1593.40002441, 1517.5 ] > > ind = np.arange(len(menMeans)) # the x locations for the groups > width = 0.8 # the width of the bars > > fig = plt.figure() > ax = fig.add_subplot(111) > rects1 = ax.bar(ind, menMeans, width, color='r') > > # add some > ax.set_ylabel('Scores') > ax.set_title('A very very long title for testing.') > > def autolabel(rects): > # attach some text labels > for rect in rects: > height = rect.get_height() > ax.text(rect.get_x()+rect.get_width()/2., 1.05*height, > '%d'%int(height), > ha='center', va='bottom') > > autolabel(rects1) > > plt.show() > [/code] > > Best regards, > > -- > LB > > LB, I can confirm the problem with zero height bars not being included in the determination of the axes limits. As for the text getting too high, this is something that many users have noticed in a variety of different scenarios. Part of the problem is that it is perfectly valid to have text outside the axes area, or straddling it, and that we have yet to come up with a decent way to handle this properly. Imagine, for example, contour labels near an axes edge. I certainly would not like to have the text labels to force the axes limits to change just to fit the text (I would rather it be clipped). Then again, your use-case is an example where auto resizing makes sense. The other issue is that it is impossible to know (in a general sense) a priori the extent of a given text object before rendering (although I think there might be some code in text.py to address this, but it might be assuming that the object has been rendered already). The particular sticking point is LaTeX strings. Therefore, rather than design a layout engine for all of matplotlib, it has become standard practice to make it easy to adjust the plot parameters programatically to deal with situations like this. For example, in your use-case, you know what the maximum bar height will be, and you know roughly how high the text will be from previous runs. You could then set the y limits to pad a certain amount on top of the maximum bar height to make sure you have enough clearance. I hope that helps, and I will take a peek at the zero-height bar issue as well. Ben Root
On 11/09/2010 07:57 PM, Jae-Joon Lee wrote: > On Wed, Nov 10, 2010 at 12:21 AM, Benjamin Root<ben...@ou...> wrote: > >> On Tue, Nov 9, 2010 at 7:24 AM, Jae-Joon Lee<lee...@gm...> wrote: >> >>> Thanks for tracking down this. >>> It turned out to be a silly error while adjusting the line end-point. >>> I'm attaching the patch. Please test the patch if you can. >>> I'll commit the change sometime tomorrow. >>> >>> > Thanks. I can reproduce the problem. > > aa = ax.annotate('', (1,1), > (-10,-10), > arrowprops=dict(arrowstyle="-|>", > fc="w", ec="k",lw=30, > path_effects=[Stroke(joinstyle='miter')]) > ) > > The erroneous behavior happens when one tries to draw a path that > connects points far outside of the canvas (point 10,10 in above > example). And this is a AGG-specific issue. The erroneous behavior > goes away if we clip the path. > > aa.arrow_patch.set_clip_box(ax.figure.bbox) > It's good to know this works. No need to implement a clipping function of our own, as I previously alluded to. > I try to reproduce the problem with simple plot command, but couldn't. > Maybe this happens only for rendering bezier splines? > Michael, any idea? > Matplotlib has its own clipping algorithm that works only on simple paths (paths without a codes array). Basic line plots fit into this category. The reason matplotlib does this rather than always relying on Agg is a) so it works in all backends, thereby saving considerable file size in vector files, and b) removing the line segments outside of the image bounds before they get stroked by Agg saves considerable time. However, this clipping algorithm is pretty simple and doesn't handle filled shapes or bezier curves, so it's turned off in those cases. > One thing I may do to prevent it is to set the clip_path of the arrow > to the figure.bbox by default. > I'll think about it. > It may make more sense to apply a global clipping rectangle of the figure to every operation (at least in the Agg backend) -- then we've fixed this once and for all. Mike > Regards, > > -JJ > > > >>> Regards, >>> >>> -JJ >>> >>> >>> On Tue, Nov 9, 2010 at 9:15 PM, Jason Grout<jas...@cr...> >>> wrote: >>> >>>> I've been trying to track down a problem in the arrows where the arrow >>>> seems to be off by a little bit. I've narrowed down the problem to a >>>> small example: >>>> >>>> import matplotlib.patches as mpatches >>>> import matplotlib.pyplot as plt >>>> fig=plt.figure() >>>> ax = fig.add_subplot(111, xlim=(.98,1.02), >>>> ylim=(.98,1.02),aspect='equal') >>>> from matplotlib.patheffects import Stroke >>>> >>>> ax.annotate('', (1,1), >>>> (0,0), >>>> arrowprops=dict(arrowstyle="-|>", >>>> fc="w", ec="k",lw=30, >>>> path_effects=[Stroke(joinstyle='miter')]),) >>>> ax.plot([0,1],[1,1]) >>>> ax.plot([1,1],[0,1]) >>>> ax.plot([0,1.02],[0,1.02]) >>>> >>>> fig.savefig('test.png') >>>> >>>> >>>> I've used a miter join above because it illustrates the problem better. >>>> Notice that the arrowhead tip is just below the line, but should be >>>> right on the line. Any clue about what the problem is? >>>> >>>> Thanks, >>>> >>>> Jason >>>> >>>> -- >>>> Jason Grout >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper >>>> David G. Thomson, author of the best-selling book "Blueprint to a >>>> Billion" shares his insights and actions to help propel your >>>> business during the next growth cycle. Listen Now! >>>> http://p.sf.net/sfu/SAP-dev2dev >>>> _______________________________________________ >>>> Matplotlib-users mailing list >>>> Mat...@li... >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper >>> David G. Thomson, author of the best-selling book "Blueprint to a >>> Billion" shares his insights and actions to help propel your >>> business during the next growth cycle. Listen Now! >>> http://p.sf.net/sfu/SAP-dev2dev >>> _______________________________________________ >>> Matplotlib-users mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >>> >>> >> Jae-Joon, >> >> I just tested out the patch, and while it did seem to fix the problem for me >> on the test script, I am not 100% certain that it is properly lined up >> (maybe an off-by-one-pixel error?). Anyway, I tried zooming in to see which >> kind of error it was and I got a very weird image. I am not certain exactly >> what triggers it, but I think if the rubber-banding does not incorporate the >> entire arrow-head, then the distortion appears. I was also able to >> reproduce the distortion without the patch (although I think it was easier >> to cause with the patch). >> >> Ben Root >> >> >> > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA
On Fri, Nov 12, 2010 at 5:11 AM, Guy Griffiths <guy...@re...>wrote: > Hi, > > I've been using matplotlib for a while for plotting scientific data, and > recently upgraded from version 0.99.1.1 to 1.0.0. Primarily I use pcolor > to > produce plots of concentration in 2D space. I use reasonably fine meshes, > and > in v0.99.1.1 the output looked great. > > In v1.0.0, all of my plots (using the same code) have faint gridlines > visible. > Since the mesh I am using is quite fine, this makes the plots look terrible > (i.e. more gridlines than actual data). This seems to be controlled by the > "edgecolors" keyword, but even when set to 'none' they are still there. Is > there any way to remove them completely without reverting back to 0.99.1.1 > (which I'd prefer not to do, since some of the API changes are really > useful > for creating very polished graphs suitable for publication)? > > imshow seems to have closer results to what I want (i.e. no gridlines), but > with imshow, the axes denote the pixel position, and there is no option to > display on polar axes (which is essential). > > Any help would be much appreciated. > > Regards, > > Guy Griffiths > > Guy, I have noticed something similar a few months ago with pcolor, but I am not certain if it is the same problem as yours. First, which backend are you using? Second, are you seeing the grid lines in both the figure window and the saved output? Also, what format are you saving your output to? Lastly, which pcolor function are you using (pcolor(), pcolormesh(), pcolorfast())? If you could include a screenshot or the saved file, I could see if it is similar to my problem. Ben Root
On Thu, Nov 11, 2010 at 9:41 PM, Martin Bures <nee...@gm...> wrote: > I am having a little issue with the matplotlib.widgets RectangleSelector. > The behavior is that the first time I try to select a region, no rectangle > draws. All subsequent uses work correctly. > > Here is how I am calling: > if self.zoomMode: > if self.canvas.widgetlock.locked(): > self.canvas.widgetlock.release( self.lasso ) > > RectangleSelector( self.ax, > self._zoom_callback, > drawtype='box', > minspanx=5, minspany=5, > spancoords='pixels' ) > else: > if self.canvas.widgetlock.locked(): > self.canvas.widgetlock.release( self.lasso ) > > if event.inaxes is None: return > > self.lasso = Lasso( event.inaxes, > ( event.xdata, event.ydata ), > self._selection_callback ) > self.canvas.widgetlock( self.lasso ) > This could be another instance of a problem resulting from our changes to how references are taken for callbacks. Try saving the RectangleSelector you create (I'm just guessing here): self.rs = RectangleSelector( self.ax, self._zoom_callback, drawtype='box', minspanx=5, minspany=5, spancoords='pixels' ) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
On Thu, Nov 11, 2010 at 7:32 PM, Michiel de Hoon <mjl...@ya...> wrote: > For this example, I am finding the exact same behavior with the Mac OS X backend as with the gtkcairo and gtkagg backends (on Mac OS X and Cygwin). If this is a bug, then which backend can we use as an example of the correct behavior for this code? On a quick test, the following script import matplotlib.pyplot as plt for i in range(4): fig = plt.figure() (no show) run with -dTkAGG and -dGTKAgg, does not raise a figure window in svn HEAD. I thought the OP was complaining that the figure was being raised w/o a call to show in macosx (don't have ready access to test on an osx box right now) JDH
On Fri, Nov 12, 2010 at 4:20 AM, Olivier Verdier <ze...@gm...> wrote: > Hi, > > I would like to use matplotlib in a programmatic way. > > I thought about creating a Figure object (with no canvas), and plot in > that Figure. > > Depending on what the user wants, I could then either plot on screen > or save on file. > > The problem is that I don't know how to connect a Figure object to the > FigureCanvas that the user chose in its preference file. In other > words, I would like to do what the function figure() does, but for an > existing Figure object. > > How could I do that? If you are using a GUI backend (eg GTKAgg, WXAgg, TkAgg, QtAgg) for your user interface and call fig.savefig with a hardcopy extension like PDF, PNG, SVG, EPS or PS, it will do the backend switching for you. If you'd like to see an example of how to do that for your own code if you need to, search for switch_backends in FigureCanvasBase: http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/backend_bases.py?revision=8791&view=markup JDH
Hi Oliver, Have you looked at any examples on the matplotlib site? For instance, there are several examples about how to use wxPython (wx) with matplotlib. Also, there is a save feature currently available in current gui when you run figure() (it is a floppy disk in navigation panel below the figure). Aman On Fri, Nov 12, 2010 at 5:20 AM, Olivier Verdier <ze...@gm...> wrote: > Hi, > > I would like to use matplotlib in a programmatic way. > > I thought about creating a Figure object (with no canvas), and plot in > that Figure. > > Depending on what the user wants, I could then either plot on screen > or save on file. > > The problem is that I don't know how to connect a Figure object to the > FigureCanvas that the user chose in its preference file. In other > words, I would like to do what the function figure() does, but for an > existing Figure object. > > How could I do that? > > Thanks! > > == Olivier > > > ------------------------------------------------------------------------------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >
On Nov 12, 2010, at 4:12 AM, Tim Åberg <qw...@ho...> wrote: > Thats seems to be what im after, diffrent resolution but that would be a easy fix i guess :) > Did you manage to run the example? i got a; > > datafile = cbook.get_sample_data('msft.csv', asfileobj=False) > AttributeError: 'module' object has no attribute 'get_sample_data' > > error > get_sample_data is only available in mpl 1.0 and later.
Hi, I've been using matplotlib for a while for plotting scientific data, and recently upgraded from version 0.99.1.1 to 1.0.0. Primarily I use pcolor to produce plots of concentration in 2D space. I use reasonably fine meshes, and in v0.99.1.1 the output looked great. In v1.0.0, all of my plots (using the same code) have faint gridlines visible. Since the mesh I am using is quite fine, this makes the plots look terrible (i.e. more gridlines than actual data). This seems to be controlled by the "edgecolors" keyword, but even when set to 'none' they are still there. Is there any way to remove them completely without reverting back to 0.99.1.1 (which I'd prefer not to do, since some of the API changes are really useful for creating very polished graphs suitable for publication)? imshow seems to have closer results to what I want (i.e. no gridlines), but with imshow, the axes denote the pixel position, and there is no option to display on polar axes (which is essential). Any help would be much appreciated. Regards, Guy Griffiths
Hi Gael, it's exactly what I need ! thanks... Gael Varoquaux wrote: > > On Fri, Nov 12, 2010 at 07:49:49AM +0000, Ian Thomas wrote: >> please is there any one can tell me if it's possible in mplot3d to >> plot >> 3d >> triangular mesh model with a colormap different from �the Z >> variable. I >> don't find example in tutorial for this. >> thanks. > >> No, this is not�possible. �Support for triangular mesh functions in >> mplot3d is currently very limited. > > If Mayavi is an option, there is a triangular mesh function available: > > http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/auto/mlab_helper_functions.html#enthought.mayavi.mlab.triangular_mesh > > Hope this helps, > > Gael > > > ------------------------------------------------------------------------------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > -- View this message in context: http://old.nabble.com/mplot3d---ploting-3d-triangular-mesh-model---need-help-tp30189662p30198364.html Sent from the matplotlib - users mailing list archive at Nabble.com.
thanks Ian for your reply, It is a pity, because it is very useful to plot simulation result on irugular 3d grid. Ian Thomas-8 wrote: > > On 11 November 2010 12:41, isolat <ill...@ya...> wrote: > >> >> hi all, >> please is there any one can tell me if it's possible in mplot3d to plot >> 3d >> triangular mesh model with a colormap different from the Z variable. I >> don't find example in tutorial for this. >> thanks. >> > > No, this is not possible. Support for triangular mesh functions in > mplot3d > is currently very limited. > > Ian > > ------------------------------------------------------------------------------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > -- View this message in context: http://old.nabble.com/mplot3d---ploting-3d-triangular-mesh-model---need-help-tp30189662p30198303.html Sent from the matplotlib - users mailing list archive at Nabble.com.
Hi, I would like to use matplotlib in a programmatic way. I thought about creating a Figure object (with no canvas), and plot in that Figure. Depending on what the user wants, I could then either plot on screen or save on file. The problem is that I don't know how to connect a Figure object to the FigureCanvas that the user chose in its preference file. In other words, I would like to do what the function figure() does, but for an existing Figure object. How could I do that? Thanks! == Olivier
Thats seems to be what im after, diffrent resolution but that would be a easy fix i guess :) Did you manage to run the example? i got a; datafile = cbook.get_sample_data('msft.csv', asfileobj=False) AttributeError: 'module' object has no attribute 'get_sample_data' error > Subject: RE: [Matplotlib-users] Linecollection, Dates on X-axis > Date: 2010年11月11日 13:44:43 +0000 > From: dav...@ub... > To: qw...@ho... > > If I've got you correctly I asked a similar question this morning on > StackOverflow. They pointed me to - > http://matplotlib.sourceforge.net/examples/pylab_examples/date_index_for > matter.html. > > > > -----Original Message----- > From: Tim-- [mailto:qw...@ho...] > Sent: Thu 11-Nov-2010 08:54 > To: mat...@li... > Subject: [Matplotlib-users] Linecollection, Dates on X-axis > > > Hello! > > I have written a program that plots values over Time, because it has to > be > done(plotted) fast the date_plot didnt fit the bill so i moved over to > Linecollection and it works like a charm. The only problem i have now is > that i dont know any easy way to get dates on the x-axis. Any ideas? > -- > View this message in context: > http://old.nabble.com/Linecollection%2C-Dates-on-X-axis-tp30188192p30188 > 192.html > Sent from the matplotlib - users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------ > ------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > Visit our website at http://www.ubs.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mails are not encrypted and cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. The sender > therefore does not accept liability for any errors or omissions in the > contents of this message which arise as a result of e-mail transmission. > If verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities > or related financial instruments. > > UBS Limited is a company limited by shares incorporated in the United > Kingdom registered in England and Wales with number 2035362. > Registered office: 1 Finsbury Avenue, London EC2M 2PP. UBS Limited > is authorised and regulated by the Financial Services Authority. > > UBS AG is a public company incorporated with limited liability in > Switzerland domiciled in the Canton of Basel-City and the Canton of > Zurich respectively registered at the Commercial Registry offices in > those Cantons with Identification No: CH-270.3.004.646-4 and having > respective head offices at Aeschenvorstadt 1, 4051 Basel and > Bahnhofstrasse 45, 8001 Zurich, Switzerland. Registered in the > United Kingdom as a foreign company with No: FC021146 and having a > UK Establishment registered at Companies House, Cardiff, with No: > BR 004507. The principal office of UK Establishment: 1 Finsbury Avenue, > London EC2M 2PP. In the United Kingdom, UBS AG is authorised and > regulated by the Financial Services Authority. > > UBS reserves the right to retain all messages. Messages are protected > and accessed only in legally justified cases.
Hi, On 12.11.2010 03:20, Jeff Whitaker wrote: > On 11/11/10 3:33 AM, Andres Luhamaa wrote: > >> Hi, >> I have a problem creating map in "aeqd" projection. The problem seems >> to be that the map center, given by arguments lon_0 and lat_0 is >> taking into account only full part of the coordinate. If I want to get >> map center at coordinates lon_0=25.5 and lat_0=58.5, I get center in >> lon_0=25 and lat_0=58, instead. I run numpy and matplotlib dev >> versions (a few weeks old) and basemap 1.0 >> >> Best regards, >> Andres Luhamaa >> > Andres: I can't reproduce this with GTKAgg or any other backend, with > basemap svn. I don't see anything that has changed since 1.0 that would > have affected this behavior though. > > -Jeff > attached images with GTKAgg and QT4Agg and python script, I added coastline to make it more clear. I may try to upgrade basemap to svn. Andres
On Fri, Nov 12, 2010 at 07:49:49AM +0000, Ian Thomas wrote: > please is there any one can tell me if it's possible in mplot3d to plot > 3d > triangular mesh model with a colormap different from the Z variable. I > don't find example in tutorial for this. > thanks. > No, this is notpossible. Support for triangular mesh functions in > mplot3d is currently very limited. If Mayavi is an option, there is a triangular mesh function available: http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/auto/mlab_helper_functions.html#enthought.mayavi.mlab.triangular_mesh Hope this helps, Gael
On 11 November 2010 12:41, isolat <ill...@ya...> wrote: > > hi all, > please is there any one can tell me if it's possible in mplot3d to plot 3d > triangular mesh model with a colormap different from the Z variable. I > don't find example in tutorial for this. > thanks. > No, this is not possible. Support for triangular mesh functions in mplot3d is currently very limited. Ian
Michiel, After some further digging I think the Mac OSX backend is probably OK. I have tried setting the backend just before I use pylab (several thousand lines into the code after setting up the GUI and lots of other stuff) the first time with code as below def display_2d(): global matplotlib_backend_set import numpy,matplotlib print 'here display2d',matplotlib_backend_set,matplotlib.rcParams['backend'] if not matplotlib_backend_set: matplotlib.use('WXAgg') # matplotlib.use('MacOSX') matplotlib_backend_set=True print 'before pylab',matplotlib.rcParams['backend'] import pylab print 'here pylab',matplotlib.rcParams['backend'] and find that if I set MacOSX backend that the import for pylab resets is 'WX' ... here display2d False WX before pylab MacOSX here pylab WX but if I set it to 'WXAgg' the pylab import doesn't reset it and it remains WxAgg ... here display2d False WX before pylab WXAgg here pylab WXAgg In the case where pylab sets WX there is the error in the x axis but in WXAgg there is no error. I can't say anything about the OSX backend though given it works on the website example code (and WX doesn't) its reasonable to expect it be OK. I thought I was using the MacOSX backend but pylab had reset it to WX behind my back ... I assumes pylab recognises that my GUI is written in wx and says the MacOSX is not the appropriate backend but it would be nice if it threw an error rather just switching backends and continuing without telling me (though I'm guessing there is no way for pylab to know that I have explicitly set a backend and in normal circumstances you'd like it to just quietly pick whatever it sees as appropriate ... and I would have never picked this up without the WX bug). > Thanks for your reply. > Just to make sure I understand correctly: Do you still think that > there is a bug in the Mac OS X backend? Or does the bug only appear > with wx? > > Best, > --Michiel. > > --- On Thu, 11/11/10, Garry Willgoose <Gar...@ne... > > wrote: > >> From: Garry Willgoose <Gar...@ne...> >> Subject: Re: [Matplotlib-users] python v ipython problem in imshow() >> To: "Michiel de Hoon" <mjl...@ya...> >> Cc: "Garry Willgoose" <Gar...@ne...>, "John >> Hunter" <jd...@gm...>, mat...@li... >> Date: Thursday, November 11, 2010, 10:00 PM >> Michiel, >> >> With some digging around in my own code I have been >> able to reproduce the bug with the matplotlib example. My >> code uses wxPython and somewhere it sets the backend to 'WX' >> (this seems to require a bit more than simply 'import wx' >> but I haven't pursued what it might be ... there are several >> thousand lines of code before I get to the plotting). >> the code below triggers the problem >> >> import wx >> import matplotlib >> print 'matplotlib backend',matplotlib.rcParams['backend'] >> matplotlib.use('WX') >> print 'matplotlib backend',matplotlib.rcParams['backend'] >> >> from pylab import * >> x = arange(100.0); x.shape = 10,10 >> interp = 'bilinear'; >> lim = -2,11,-2,6 >> subplot(211, axisbg='g') >> title('blue should be up') >> imshow(x, origin='upper', interpolation=interp) >> subplot(212, axisbg='y') >> title('blue should be down') >> imshow(x, origin='lower', interpolation=interp) >> show() >> >> >> if I set the backend to WxAgg then the problem doesn't >> occur and if I don't set it all (so its MacOSX) then all is >> fine. In the example above the top graph is fine but the >> lower one is solid yellow. This behaviour is different from >> my code which shows the same image for both origin='upper' >> and 'lower'. My platform is enthought 6.1-1 with matplotlib >> 0.99.1.1. >> >> Given that WXAgg works are there any are the implications >> of WXAgg early in my plotting part of the code (this may >> result in multiple calls to set the backend) versus letting >> matplotlib itself set WX. I just tried to set WXAgg >> immediately after the first 'import wx' after program >> startup but it had set to WX by the time it got the place >> where the plots were made. >> >>> I haven't been able to replicate this bug. With all >> matplotlib versions >>> I tried (including 0.99.0, 0.99.1., 0.99.1.1, >> 0.99.1.2, 1.0.0, and the current source code in svn), this >> example works correctly with the Mac OS X backend. >>> Garry, what is the exact code that you are using? >>> >>> --Michiel. >>> >>> >>> --- On Wed, 11/10/10, John Hunter <jd...@gm...> >> wrote: >>> >>>> From: John Hunter <jd...@gm...> >>>> Subject: Re: [Matplotlib-users] python v ipython >> problem in imshow() >>>> To: "Michiel de Hoon" <mjl...@ya...> >>>> Cc: "Garry Willgoose" <Gar...@ne...>, >> mat...@li... >>>> Date: Wednesday, November 10, 2010, 10:59 AM >>>> On Wed, Nov 10, 2010 at 9:48 AM, >>>> Michiel de Hoon <mjl...@ya...> >>>> wrote: >>>>> Garry, if the bug still exists in matplotlib >> 1.0 could >>>> you open a bug report for it? >>>> >>>> >>>> I think Gary doesn't have easy access to >> 1.0. Here is >>>> the relevant >>>> example if anyone has 1.0 on macosx to test with >>>> >>>> http://matplotlib.sourceforge.net/examples/pylab_examples/image_origin.html >>>> >>>> JDH >>>> >>> >>> >>> >>> >>> >> ------------------------------------------------------------------------------ >>> Centralized Desktop Delivery: Dell and VMware >> Reference Architecture >>> Simplifying enterprise desktop deployment and >> management using >>> Dell EqualLogic storage and VMware View: A highly >> scalable, end-to-end >>> client virtualization framework. Read more! >>> http://p.sf.net/sfu/dell-eql-dev2dev >>> _______________________________________________ >>> Matplotlib-users mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >> ==================================================================== >> Prof Garry Willgoose, >> Australian Professorial Fellow in Environmental >> Engineering, >> Director, Centre for Climate Impact Management (C2IM), >> School of Engineering, The University of Newcastle, >> Callaghan, 2308 >> Australia. >> >> Centre webpage: www.c2im.org.au >> >> Phone: (International) +61 2 4921 6050 (Tues-Fri AM); +61 2 >> 6545 9574 (Fri PM-Mon) >> FAX: (International) +61 2 4921 6991 (Uni); +61 2 6545 9574 >> (personal and Telluric) >> Env. Engg. Secretary: (International) +61 2 4921 6042 >> >> email: gar...@ne...; >> g.w...@te... >> email-for-life: gar...@al... >> personal webpage: www.telluricresearch.com/garry >> ==================================================================== >> "Do not go where the path may lead, go instead where there >> is no path and leave a trail" >> >> Ralph Waldo Emerson >> ==================================================================== >> >> >> >> >> >> > > > > > ------------------------------------------------------------------------------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users ==================================================================== Prof Garry Willgoose, Australian Professorial Fellow in Environmental Engineering, Director, Centre for Climate Impact Management (C2IM), School of Engineering, The University of Newcastle, Callaghan, 2308 Australia. Centre webpage: www.c2im.org.au Phone: (International) +61 2 4921 6050 (Tues-Fri AM); +61 2 6545 9574 (Fri PM-Mon) FAX: (International) +61 2 4921 6991 (Uni); +61 2 6545 9574 (personal and Telluric) Env. Engg. Secretary: (International) +61 2 4921 6042 email: gar...@ne...; g.w...@te... email-for-life: gar...@al... personal webpage: www.telluricresearch.com/garry ==================================================================== "Do not go where the path may lead, go instead where there is no path and leave a trail" Ralph Waldo Emerson ====================================================================
Thanks for your reply. Just to make sure I understand correctly: Do you still think that there is a bug in the Mac OS X backend? Or does the bug only appear with wx? Best, --Michiel. --- On Thu, 11/11/10, Garry Willgoose <Gar...@ne...> wrote: > From: Garry Willgoose <Gar...@ne...> > Subject: Re: [Matplotlib-users] python v ipython problem in imshow() > To: "Michiel de Hoon" <mjl...@ya...> > Cc: "Garry Willgoose" <Gar...@ne...>, "John Hunter" <jd...@gm...>, mat...@li... > Date: Thursday, November 11, 2010, 10:00 PM > Michiel, > > With some digging around in my own code I have been > able to reproduce the bug with the matplotlib example. My > code uses wxPython and somewhere it sets the backend to 'WX' > (this seems to require a bit more than simply 'import wx' > but I haven't pursued what it might be ... there are several > thousand lines of code before I get to the plotting). > the code below triggers the problem > > import wx > import matplotlib > print 'matplotlib backend',matplotlib.rcParams['backend'] > matplotlib.use('WX') > print 'matplotlib backend',matplotlib.rcParams['backend'] > > from pylab import * > x = arange(100.0); x.shape = 10,10 > interp = 'bilinear'; > lim = -2,11,-2,6 > subplot(211, axisbg='g') > title('blue should be up') > imshow(x, origin='upper', interpolation=interp) > subplot(212, axisbg='y') > title('blue should be down') > imshow(x, origin='lower', interpolation=interp) > show() > > > if I set the backend to WxAgg then the problem doesn't > occur and if I don't set it all (so its MacOSX) then all is > fine. In the example above the top graph is fine but the > lower one is solid yellow. This behaviour is different from > my code which shows the same image for both origin='upper' > and 'lower'. My platform is enthought 6.1-1 with matplotlib > 0.99.1.1. > > Given that WXAgg works are there any are the implications > of WXAgg early in my plotting part of the code (this may > result in multiple calls to set the backend) versus letting > matplotlib itself set WX. I just tried to set WXAgg > immediately after the first 'import wx' after program > startup but it had set to WX by the time it got the place > where the plots were made. > > > I haven't been able to replicate this bug. With all > matplotlib versions > > I tried (including 0.99.0, 0.99.1., 0.99.1.1, > 0.99.1.2, 1.0.0, and the current source code in svn), this > example works correctly with the Mac OS X backend. > > Garry, what is the exact code that you are using? > > > > --Michiel. > > > > > > --- On Wed, 11/10/10, John Hunter <jd...@gm...> > wrote: > > > >> From: John Hunter <jd...@gm...> > >> Subject: Re: [Matplotlib-users] python v ipython > problem in imshow() > >> To: "Michiel de Hoon" <mjl...@ya...> > >> Cc: "Garry Willgoose" <Gar...@ne...>, > mat...@li... > >> Date: Wednesday, November 10, 2010, 10:59 AM > >> On Wed, Nov 10, 2010 at 9:48 AM, > >> Michiel de Hoon <mjl...@ya...> > >> wrote: > >>> Garry, if the bug still exists in matplotlib > 1.0 could > >> you open a bug report for it? > >> > >> > >> I think Gary doesn't have easy access to > 1.0. Here is > >> the relevant > >> example if anyone has 1.0 on macosx to test with > >> > >> http://matplotlib.sourceforge.net/examples/pylab_examples/image_origin.html > >> > >> JDH > >> > > > > > > > > > > > ------------------------------------------------------------------------------ > > Centralized Desktop Delivery: Dell and VMware > Reference Architecture > > Simplifying enterprise desktop deployment and > management using > > Dell EqualLogic storage and VMware View: A highly > scalable, end-to-end > > client virtualization framework. Read more! > > http://p.sf.net/sfu/dell-eql-dev2dev > > _______________________________________________ > > Matplotlib-users mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > ==================================================================== > Prof Garry Willgoose, > Australian Professorial Fellow in Environmental > Engineering, > Director, Centre for Climate Impact Management (C2IM), > School of Engineering, The University of Newcastle, > Callaghan, 2308 > Australia. > > Centre webpage: www.c2im.org.au > > Phone: (International) +61 2 4921 6050 (Tues-Fri AM); +61 2 > 6545 9574 (Fri PM-Mon) > FAX: (International) +61 2 4921 6991 (Uni); +61 2 6545 9574 > (personal and Telluric) > Env. Engg. Secretary: (International) +61 2 4921 6042 > > email: gar...@ne...; > g.w...@te... > email-for-life: gar...@al... > personal webpage: www.telluricresearch.com/garry > ==================================================================== > "Do not go where the path may lead, go instead where there > is no path and leave a trail" > > Ralph Waldo Emerson > ==================================================================== > > > > > >
I am having a little issue with the matplotlib.widgets RectangleSelector. The behavior is that the first time I try to select a region, no rectangle draws. All subsequent uses work correctly. Here is how I am calling: if self.zoomMode: if self.canvas.widgetlock.locked(): self.canvas.widgetlock.release( self.lasso ) RectangleSelector( self.ax, self._zoom_callback, drawtype='box', minspanx=5, minspany=5, spancoords='pixels' ) else: if self.canvas.widgetlock.locked(): self.canvas.widgetlock.release( self.lasso ) if event.inaxes is None: return self.lasso = Lasso( event.inaxes, ( event.xdata, event.ydata ), self._selection_callback ) self.canvas.widgetlock( self.lasso ) I have attempted to debug this behavior. If I breakpoint at the call to RectangleSelector and then step in, selection works as-expected on the first call. However, if I move the breakpoint into the callback, it does not work correctly on the first call and the breakpoint is not reached. Again, all subsequent uses work correctly. Any thoughts? I am using 0.99.1.1 on Ubuntu 10.04 Linux martin-laptop 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux '/usr/lib/pymodules/python2.6/matplotlib/__init__.pyc' Thanks. martin.