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
|
From: John H. <jdh...@ac...> - 2004-05-21 14:43:25
|
>>>>> "Andrew" == Andrew Straw <str...@as...> writes: Andrew> Hi all, I'd like use matplotlib to draw shapes on a Andrew> transparent background using the Agg backend to save .png Andrew> files. Is this possible? Andrew> I've tried Andrew> fig._figurePatch.set_alpha(0) There is a vestigial limitation from the bad old days when we didn't have an alpha channel. For polyons, there is no place holder for a separate alpha channel for the edge and face. The way to do this right is to simply replace all rgb instances throughout the library with rgba, but this is a fair amount of work that touches the entire library. What I am doing currently is sharing the alpha attribute between edge and face for polygons. So setting alpha=0 *should work. What backend and version are you using? Rectangle calls gc.set_alpha before calling draw_polygon in patches.Patch. In _backend_agg.RendererAgg.draw_polygon, the alpha attribute for the face is taken from the edge which gets it from the gc (around line 204 in _backend_agg). I say all this just because from my read of the code *it should* work, and indeed, in my tests f = figure(1, facecolor='r') f._figurePatch.set_alpha(0.0) does work for me using Agg and the latest matplotlib. What backend and version are you using? That said, the best way to do this is to add a frameon attribute for figures, because this will be respected across backends including those who don't understand alpha. This way you can say f = figure(1, frameon=False) I checked this into CVS. JDH Andrew> This seems to get halfway, but there's still (opaque) Andrew> white drawn in the background. Andrew> Is there a "recommended way", and, if so, what is it? Andrew> Otherwise, can we improve matplotlib to allow drawing on Andrew> transparent backgrounds? Andrew> Cheers! Andrew Andrew> ------------------------------------------------------- Andrew> This SF.Net email is sponsored by: Oracle 10g Get Andrew> certified on the hottest thing ever to hit the Andrew> market... Oracle 10g. Take an Oracle 10g class now, and Andrew> we'll give you the exam FREE. Andrew> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click Andrew> _______________________________________________ Andrew> Matplotlib-users mailing list Andrew> Mat...@li... Andrew> https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
From: John H. <jdh...@ac...> - 2004-05-21 14:20:44
|
>>>>> "MWallis" == MWallis <mw...@sw...> writes: MWallis> I have 5 plots in one window that I am updating MWallis> dynamically and the GUI starts to freeze. Each of the MWallis> plots has its own timeout. Is there a better way of MWallis> doing this or can I put the plots on different threads? MWallis> Any suggestions would be appreciated. Hi Melissa, You may look into doing an idle_add instead of a timeout_add. The former only draws when the processor is idle. Perhaps it is taking you longer to draw than the frequency that you are calling the draw functions with the timer, getting you into trouble. Also, you had asked earlier about one canvas with many axes versus many canvases embedded in GTK and my answer was it "it depends on layout considerations". Now that I see better what you are trying to do, I'd like to add that it will likely be more efficient to dynamically update several axes on the same canvas than to separately update many canvases. def myfunc(*args): # update all the figures and draw return gtk.TRUE idle_add(c.idle_function) JDH |
From: Andrew S. <str...@as...> - 2004-05-20 22:21:12
|
when running the following simple script: from matplotlib.matlab import * from numarray import * theta = arange(0.0,8*pi,0.1) a=1 b=.2 dt = 0.0 x = a*cos( theta )*exp(b*theta) y = a*sin( theta )*exp(b*theta) plot(x,y) show() #savefig('ss') with the following combination of software: matplotlib 0.54 numarray 0.9 python 2.2.1 windows XP if I use WXAgg or Agg, I get this: Traceback (most recent call last): File "simple_spiral.py", line 13, in ? show() File "C:\Python22\Lib\site-packages\matplotlib\backends\backend_wx.py", line 1124, in show figwin.canvas.draw() File "C:\Python22\Lib\site-packages\matplotlib\backends\backend_wxagg.py", line 50, in draw agg.draw() File "C:\Python22\Lib\site-packages\matplotlib\backends\backend_agg.py", line 299, in draw self.figure.draw(self.renderer) File "C:\Python22\Lib\site-packages\matplotlib\figure.py", line 128, in draw for a in self.axes: a.draw(renderer) File "C:\Python22\Lib\site-packages\matplotlib\axes.py", line 603, in draw self.xaxis.draw(renderer) File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 463, in draw tick.draw(renderer) File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 125, in draw if midPoint and self.tick1On: self.tick1line.draw(renderer) File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 193, in draw self._lineFunc(renderer, gc, xt, yt) File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 326, in _draw_solid renderer.draw_lines(gc, xt,yt) TypeError: can't convert complex to float; use e.g. abs(z) if I use PS, I get this: Traceback (most recent call last): File "simple_spiral.py", line 14, in ? savefig('ss') File "C:\Python22\Lib\site-packages\matplotlib\matlab.py", line 1156, in savefig manager.canvas.print_figure(*args, **kwargs) File "C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 378, in print_figure self.figure.draw(renderer) File "C:\Python22\Lib\site-packages\matplotlib\figure.py", line 128, in draw for a in self.axes: a.draw(renderer) File "C:\Python22\Lib\site-packages\matplotlib\axes.py", line 603, in draw self.xaxis.draw(renderer) File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 463, in draw tick.draw(renderer) File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 125, in draw if midPoint and self.tick1On: self.tick1line.draw(renderer) File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 193, in draw self._lineFunc(renderer, gc, xt, yt) File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 326, in _draw_solid renderer.draw_lines(gc, xt,yt) File "C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 103, in draw_lines ps.append('newpath %s moveto' % _nums_to_str((x[0], y[0]))) File "C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 36, in _nums_to_str return ' '.join([_int_or_float(val, fmt) for val in seq]) File "C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 41, in _int_or_float ival = int(val) TypeError: can't convert complex to int; use e.g. int(abs(z)) |
From: Andrew S. <str...@as...> - 2004-05-20 21:27:54
|
Hi all, I'd like use matplotlib to draw shapes on a transparent background using the Agg backend to save .png files. Is this possible? I've tried fig._figurePatch.set_alpha(0) This seems to get halfway, but there's still (opaque) white drawn in the background. Is there a "recommended way", and, if so, what is it? Otherwise, can we improve matplotlib to allow drawing on transparent backgrounds? Cheers! Andrew |
From: John H. <jdh...@ac...> - 2004-05-20 14:45:37
|
>>>>> "MWallis" == MWallis <mw...@sw...> writes: MWallis> I am trying to dynamically update some figures that I MWallis> have embedded in GTK. The figures display fine and if I MWallis> minimize and then maximize the window the figures update MWallis> but I can't get the figures to update dynamically as you MWallis> watch the window. To try and get this working I used the MWallis> code from one of the dynamic samples and just embedded it MWallis> in my application. Hi Melissa, You were using kind of a hybrid of what I call the matlab interface and the application interface, so I rewrote your example in the way I would do it if I were embedding the dynamic demo in a GTK application. The code is for the latest release (0.54) where some of the API changed as discussed in the release notes, and would be slightly different for earlier versions of matplotlib. The major difference is that under the new API, you create axes and subplots from a Figure instance with, for example, self.ax = self.figure.add_subplot(111) Hope this helps, John import pygtk pygtk.require('2.0') import gtk import time from matplotlib.backends.backend_gtkagg import FigureCanvasGTKAgg as FigureCanvas from matplotlib.figure import Figure from matplotlib.matlab import * class C: def __init__(self): self.figure = Figure( figsize=(8,6), dpi=72) self.canvas = FigureCanvas(self.figure) # a gtk.DrawingArea self.ax = self.figure.add_subplot(111) self.win = gtk.Window() self.win.set_name("Embedding in GTK") self.win.connect("destroy", gtk.mainquit) self.win.set_border_width(5) self.win.add(self.canvas) def create_AntennaResponseDisplay (self, title): ind = arange(1,9) p1,p2,p3,p4,p5,p6,p7,p8 = self.ax.bar(ind, self.get_stats()) centers = ind + 0.5*p1.get_width() p1.set_facecolor('b') p2.set_facecolor('b') p3.set_facecolor('b') p4.set_facecolor('b') p5.set_facecolor('b') p6.set_facecolor('b') p7.set_facecolor('b') p8.set_facecolor('b') self.ax.set_xlim([0.5,9]) self.ax.set_xticks(centers) self.ax.set_ylim([0,100]) self.ax.set_xticklabels(['1', '2', '3', '4', '5', '6', '7', '8']) t = self.figure.text(0.5, 0.95, title, horizontalalignment = 'center', fontsize = 10,) def updatefig(*args): e1, e2, e3, e4, e5, e6, e7, e8 = self.get_stats() p1.set_height(e1) p2.set_height(e2) p3.set_height(e3) p4.set_height(e4) p5.set_height(e5) p6.set_height(e6) p7.set_height(e7) p8.set_height(e8) self.ax.set_ylim([0,100]) self.canvas.draw() return gtk.TRUE gtk.timeout_add(250, updatefig) self.canvas.show() self.win.show() gtk.mainloop() def get_memory(self): "Simulate a function that returns system memory" return 100*(0.5+0.5*sin(0.5*pi*time.time())) def get_cpu(self): "Simulate a function that returns cpu usage" return 100*(0.5+0.5*sin(0.2*pi*(time.time()-0.25))) def get_net(self): "Simulate a function that returns network bandwidth" return 100*(0.5+0.5*sin(0.7*pi*(time.time()-0.1))) def get_stats(self): return self.get_memory(), self.get_cpu(), self.get_net(), \ self.get_memory(), self.get_cpu(), self.get_net(), \ self.get_memory(), self.get_cpu() c = C() c.create_AntennaResponseDisplay('Test!') |
From: John H. <jdh...@ac...> - 2004-05-20 14:26:11
|
What's new in matplotlib 0.54 ============================= I've done a lot of rewriting of the core of matplotlib to support some new features - mainly fast handling of polygon collections (pcolor and scatter) and since the changes were pervasive, I took to opportunity to fix some things that were bugging me about the design of matplotlib. If you use the API, creating your own Axes, Subplots, Lines, Rectangles, Texts, or working directly with transforms and bboxes, you will need to upgrade your code, since the constructors of all these objects have been simplified. The major changes affecting users of the matlab interface are for pcolor and scatter. These changes and others are detailed below and in http://matplotlib.sf.net/API_CHANGES. Sorry for the pain - in the long run, the new design is much cleaner and easier to work with, and as far as I can see, will be stable. More general transformation architecture ---------------------------------------- Earlier versions of matplotlib handled transformation of x and y separately (ie we assumed all transformations were separable) but this makes is difficult to do rotations or polar transformations, for example. The new transformation lays the framework for doing general transformations; see the transforms module http://matplotlib.sf.net/matplotlib.transforms.html. More efficient pcolor --------------------- pcolor is now implemented with matplotlib.collections. polygon collections which should provide significantly faster performance across backends. The return value from pcolor is now a PolyColleciton object rather than a list of patches, but the API is largely compatible. See http://matplotlib.sf.net/API_CHANGES. The old function pcolor_classic is retained for full backward compatibility. New scatter plots ----------------- The http://matplotlib.sf.net/matplotlib.matlab.html#-scatter command is rewritten, and is implemented in the backend with a new polygon collection class. For large scatter plots, the performance is 5 times faster across all backends and 10 times faster for the *Agg backends. Also, scatter works with many symbols: diamonds, sqaures, oriented triangles, circles and more. As with pcolor, the scatter command returns a collection instance rather than a list of patches as before; see See http://matplotlib.sf.net/API_CHANGES Also the size argument is now in points^2 (the area of the symbol in points) and is not in data coords as before. This fixes a few problems: symbols are not skewed by unequally shaped axes, scatter works with log coords w/o distoring the symbol, and it is matlab compatible. The function scatter_classic is the old scatter function and will work identically. Enhanced mathtext ----------------- A significant rewrite of the mathtext module provides much more precise layout. The freetype component has been factored out of the layout engine and replaced by an abstract class for font handling. This lays the groundwork for ps mathtext. The text clipping problems have been fixed. Added spacing commands '\/' (small space) and '\ ' (regular space), and '\hspace{frac}' (space is fraction of pointsize) as well as composite chars such as \angstrom. Fixed over/under subscripts so you can say x_i^j and nested subscripts if you do x_i_{j} (you need the curlys) Many new plot symbols and markers --------------------------------- Thanks Gary Ruben. See http://matplotlib.sf.net/matplotlib.matlab.html#-plot Font cacheing ------------- Paul Barrett added caching support to the font manager to increase performance. This and other changes have dramatically improved postscript backend performance. Newlines in text ---------------- After much encouragement from Al, I finally got around to supporting newline separated text in the Text frontend, so this is no longer backend dependent. As a bonus, it even works with arbitrary rotations. There is an additional text attribute 'multialignment' that specifies the alignment of the lines in multiline text. See http://matplotlib.sf.net/examples/multiline.py and http://matplotlib.sf.net/screenshots.html#align_text. Works with all text instances except mathtext. Axes hold --------- matlab compatible hold command determines whether subsequent plot commands overlay current plot or clear the axes by default. Default setting is set in matplotlibrc and toggled by the hold command. New rc file options ------------------- You can control grid properties and tick padding (the space between the axes and tick label) in matplotlibrc. The new options and defaults are axes.hold : True # whether to clear the axes by default on # each plot command. Toggle with hold command grid.color : k # grid color grid.linestyle : : # dotted grid.linewidth : 0.5 # in points tick.major.pad : 4 # distance to major tick label in points tick.minor.pad : 4 # distance to the minor tick label in points Full dash control ----------------- You can precisely control the dashes with a sequence of on off ink in points. See http://matplotlib.sf.net/examples/dash_control.py Removed close buttons from GUI ------------------------------ Steve Chaplin persuasively argued these were a bad idea. It's taken me a while not to instinctively try and click on the missing buttons, but I'm used to it now. Properly aligned text with arbitrary alignments ----------------------------------------------- You can now expect horizontal and vertical alignment specifications to work with text at an arbitrary angle, eg, 45 degrees. See http://matplotlib.sf.net/examples/alignment_test.py Added stem plotting command --------------------------- See http://matplotlib.sf.net/matplotlib.matlab.html#-stem and http://matplotlib.sf.net/examples/stem_plot.py Bug fix roundup --------------- Executive summary: fixed ps centering, errorbar autoscaling, constant data plot, copy tick attribute, mathtext fontsizing in interactive mode, missing draw if interactive, some numerix/numarray incompatibilities in type handling, agg memory leak, wx tooltips and close not returning interpreter. See http://matplotlib.sf.net/CHANGELOG for details. Downloads at http://sourceforge.net/projects/matplotlib |
From: Flavio C. C. <fcc...@ci...> - 2004-05-17 22:43:29
|
has anyone come across this bug? >>> from matplotlib.matlab import * >>> a = arange(10) >>> a.shape (10,) >>> plot(a) [<matplotlib.lines.Line2D instance at 0x4147712c>] >>> show() this plot works ok but if we turn a into a one dimensional array then... >>> a.shape=(10,1) >>> a.shape (10, 1) >>> plot(a) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.3/site-packages/matplotlib/matlab.py", line 941, in plot try: lines = gca().plot(*args, **kwargs) File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 1181, in plot self.yaxis.autoscale_view() File "/usr/lib/python2.3/site-packages/matplotlib/axis.py", line 405, in autoscale_view tup = self._majorTicker.locator.autoscale() File "/usr/lib/python2.3/site-packages/matplotlib/ticker.py", line 578, in autoscale self._locator = self.get_locator(d) File "/usr/lib/python2.3/site-packages/matplotlib/ticker.py", line 589, in get_locator fld = math.floor(ld) TypeError: only rank-0 arrays can be converted to Python scalars. >>> |
From: John H. <jdh...@ac...> - 2004-05-14 19:20:45
|
>>>>> "Todd" == Todd Miller <jm...@st...> writes: Todd> (2) I could just build a numarray version of the matplotlob Todd> installer with each release. That would offload the work Todd> from you and would keep the matplotlib code cleaner. If you want to do that I have no objections - I like this better than maintaining both in a single build. I think we need to make the matplotlib code work with either build (eg using the nx.Type scheme you proposed) so that if the user switches their numerix setting with a given build everything still works. But if there is interest in a numarray build for win32, I see no reason why not. We should probably be careful to coordinate so that the two releases are as similar as possible, with the only difference being the default numerix setting in the rc file. JDH |
From: John H. <jdh...@ac...> - 2004-05-14 19:16:35
|
>>>>> "Perry" == Perry Greenfield <pe...@st...> writes: Perry> I had looked at that. I'm a little confused by the Perry> terminology though. This sounds like a prescription for Perry> changing the defaults for some parameters for a session Perry> rather than for a single figure. Do I misread that? (Also, Perry> on my browser these entries are much wider than the browser Perry> window for some reason; later in the faq that changes as do Perry> some of the fonts. I wonder if something is screwed up Perry> there). You were rightfully confused. It said figure when it should say session. I mainly work from scripts, with one figure per script, so I was just munging them in my mind. I made a brief update to the FAQ in my own tree, but with the dynamic customization you discuss below, this will need to be updated again. As for the browser problem, I have the same. I tried to spot an html error that would explain it but haven't found it yet. Perry> Changing the use of the rcParams to be immediate rather Perry> than locked in at module initialization is more attractive Perry> to me (and may allow one to assign differnt rc sets to Perry> different backends by default as well; but that is not Perry> urgent). Do you mind changing when the parameters are Perry> picked up? (I'm asking that you do it now, just whether Perry> that is acceptable). This seems like the way to go. Nothing really speaks against it except the slightly inelegant use of a bunch of Nones in the constructors. I'm happy to make the changes, or leave it to one of you. JDH |
From: Perry G. <pe...@st...> - 2004-05-14 17:36:48
|
John Hunter wrote: > >>>>> "Perry" == Perry Greenfield <pe...@st...> writes: > > Perry> Is there a means of using alternate rcParams dictionaries > Perry> for use with different backends, say as a parameter to the > Perry> print_figure method? It doesn't look like it at the > Perry> moment. I'd guess to do that now means replacing rcParams > Perry> temporarily, rendering the plot to the file, and resetting > Perry> rcParams to what it was (I haven't actually tried it), but > Perry> that seems clumsier than it should be. > > There are a few ways to go here. > > Probably the best is based on the answer to "How do I customize the > default behavior of a single figure?" > http://matplotlib.sourceforge.net/faq.html#CUSTOM > I had looked at that. I'm a little confused by the terminology though. This sounds like a prescription for changing the defaults for some parameters for a session rather than for a single figure. Do I misread that? (Also, on my browser these entries are much wider than the browser window for some reason; later in the faq that changes as do some of the fonts. I wonder if something is screwed up there). [details about setting up session context and object intialization snipped] I'm thinking of the case where someone tailors plots interactively and then wants to render the same plot, but with different defaults for a png file or postscript in the same session. In that case a session change of default isn't very useful. They basically are going to be force to write a script, and run it from a different session to get a different version. So I think that is going to be somewhat inconvenient for some users. Changing the use of the rcParams to be immediate rather than locked in at module initialization is more attractive to me (and may allow one to assign differnt rc sets to different backends by default as well; but that is not urgent). Do you mind changing when the parameters are picked up? (I'm asking that you do it now, just whether that is acceptable). Thanks, Perry |
From: John H. <jdh...@ac...> - 2004-05-14 16:00:33
|
>>>>> "Perry" == Perry Greenfield <pe...@st...> writes: Perry> Is there a means of using alternate rcParams dictionaries Perry> for use with different backends, say as a parameter to the Perry> print_figure method? It doesn't look like it at the Perry> moment. I'd guess to do that now means replacing rcParams Perry> temporarily, rendering the plot to the file, and resetting Perry> rcParams to what it was (I haven't actually tried it), but Perry> that seems clumsier than it should be. There are a few ways to go here. Probably the best is based on the answer to "How do I customize the default behavior of a single figure?" http://matplotlib.sourceforge.net/faq.html#CUSTOM Ie, you can set the rc params for a given session by updating the rc dict before importing matplotlib. You could set up a module like plot_contexts plot_contexts.py:: from matplotlib import rcParams def use(s): if s == 'powerpoint': rcParams['figure.facecolor'] = 'b' rcParams['text.fontname'] = 'cmr10' rcParams['lines.linewidth'] = 2.0 elif s = 'some journal' and so on And at the script level you could do import plot_contexts plot_contexts.use('powerpoint') from matplotlib.matlab import * The one down side of the rcParams approach is that currently all the object defaults are evaluated at module load time, so you can only switch at the start of your python session. Eg, the current constructors look like class Line2D(Artist): def __init__(self, xdata, ydata, linewidth=rcParams['lines.linewidth'], linestyle=rcParams['lines.linestyle'], ) By changing all the constructor defaults to def __init__(self, xdata, ydata, linewidth=None, linestyle=None, ): if linewidth is None: linewidth = rcParams['lines.linewidth'], if linestyle is None: linestyle = rcParams['lines.linestyle'], we could defer those evaluations to construction time, so you could switch contexts in the middle of an interactive session >>> plot_contexts.use('power point') >>> make_some_figs() >>> plot_contexts.use('some journal') >>> make_some_figs() # again I already did this for the FontProperties so you can have context fonts, as in examples/font_properties_demo.py. It wouldn't be much work to do the same for the other properties controlled by rc. As another approach, I have considered making the matplotlibrc finder check the current dir first, and using that file if it finds one. Then you could have dir based contexts. JDH |
From: Perry G. <pe...@st...> - 2004-05-14 15:43:31
|
I wonder what the recommended way of saving and using different plotting defaults is. Let me give some background first. While many users like the current window color defaults (basically black on white) some prefer white on black for interactive use (for one thing, colors stand out more). And while they may be morons for wanting to do so ;-), there is also a very good reason to use such a color scheme for viewgraphs. I don't know how many times I've suffered through a presentation where the presenter showed the plots having a white background and colored lines or symbols. In that setting, colors just don't show well. ("well, you could see the yellow points in my version...") On the other hand such color schemes don't print well (and the current one does). I could see someone wanting 2 or 3 different contexts. The current rcParams does allow for different save color faces, but that isn't quite enough for cases where text needs to be white or something other than black to show up against black bacgrounds. Is there a means of using alternate rcParams dictionaries for use with different backends, say as a parameter to the print_figure method? It doesn't look like it at the moment. I'd guess to do that now means replacing rcParams temporarily, rendering the plot to the file, and resetting rcParams to what it was (I haven't actually tried it), but that seems clumsier than it should be. Perry |
From: Todd M. <jm...@st...> - 2004-05-14 15:38:41
|
On Fri, 2004-05-14 at 11:27, Perry Greenfield wrote: > Todd Miller wrote: > > > > So, while this feels like walking backward, you can say: > > > > y = int(self.height) - y.astype('s') > > > > and expect it to work with either. > > > If this is used as the workaround, perhaps local (to the module) > versions of Int16 and such can be defined as 's' and so forth > so that it will be easier to update code rather than litter > it with such character codes. > > Perry Good idea. I'll see if I can get numerix to take care of it. Todd |
From: Perry G. <pe...@st...> - 2004-05-14 15:28:06
|
Todd Miller wrote: > > So, while this feels like walking backward, you can say: > > y = int(self.height) - y.astype('s') > > and expect it to work with either. > If this is used as the workaround, perhaps local (to the module) versions of Int16 and such can be defined as 's' and so forth so that it will be easier to update code rather than litter it with such character codes. Perry |
From: Todd M. <jm...@st...> - 2004-05-14 14:33:04
|
On Fri, 2004-05-14 at 08:35, John Hunter wrote: > The new transformation module I've been working on is implemented in > extension code. It offers a couple of important benefits, namely > speed and generality (affines, nonseparable xy transformations). It's > not in CVS yet because I'm still ironing out the details. > > I have two methods for operating over sequences of x and y, seq_x_y > and numerix_x_y. The first uses the python sequence API and the > second uses the numerix api. I expect the latter will be a good bit > faster for long lines, since it doesn't have the python object type > coercion to deal with, but I haven't profiled it. > > But there is a gotcha. When I compile the code, I use flag in > setup.py to indicate whether to compile with Numeric or numarray. > This sets a flag and that is used in the transforms module (and the > image module) that will import arrayobject.h from either Numeric or > numarray. > > A problem can arise if someone compiles with one and uses a different > setting in ~/.matplotlibrc. I compiled the module with Numeric but > used numarray in my matplotlibrc. The transformation went fine, > presumably thanks to the numarray compatibility layer. I passed the > transformed arrays off to one of the backends, which does > > from matplotlib.numerix import Int16 > > y = int(self.height) - y.astype(Int16) > > and got a > > ValueError: type must be either a 1-length string, or python type > object > > clearly because of the difference between numpy and numarray type > args. Yeah. numarray has full blown type objects which form a hierarchy which can be used to test for type properties such as signed, integral, etc. numarray uses names for its type objects that were used by Numeric to make 1 character typecodes clearer and easier to remember. Thus, in numarray Int16 is an object, but in Numeric Int16 is an alias for 's'. Over time, our compatibility ambitions have grown so now numarray generally works with Numeric typecodes wherever a type object is expected. So, while this feels like walking backward, you can say: y = int(self.height) - y.astype('s') and expect it to work with either. > Another question is win32, where the user doesn't have the choice at > compile time. If we compile in numpy for win32, the user's numarrays > will be transformed into numpys at render time, but this won't affect > the user arrays (unlike in scipy where the user is getting the return > values) so I don't see it as a big deal. I think trying to compile in > both or supplying alternate binaries is doable but may not be worth > the maintenance and complexity. > > In any case, there are a couple of readers here who know a bit more > about numarray and numeric than I do <wink> ; any thoughts? (1) One thought I've had for handling this has been to improve the basic binary compatibility of numarray with Numeric to the point that numerix can be extended to the C-level. In this scheme, an extension would be compiled against neither numarray nor Numeric but against numerix; which array package was actually being used would be figured out at run time much as it works at the Python level now. I'm still exploring the idea. (2) I could just build a numarray version of the matplotlob installer with each release. That would offload the work from you and would keep the matplotlib code cleaner. Todd |
From: Perry G. <pe...@st...> - 2004-05-14 13:37:25
|
John Hunter wrote: > Is there a clever workaround for this problem? It doesn't affect any > of the agg or PS backends. GTK and GD both need to convert their > arrays to ints before passing them on to their respective renderers. > One solution is to do the conversion in list comps [...] > Another question is win32, where the user doesn't have the choice at > compile time. If we compile in numpy for win32, the user's numarrays > will be transformed into numpys at render time, but this won't affect > the user arrays (unlike in scipy where the user is getting the return > values) so I don't see it as a big deal. I think trying to compile in > both or supplying alternate binaries is doable but may not be worth > the maintenance and complexity. [...] > > In any case, there are a couple of readers here who know a bit more > about numarray and numeric than I do <wink> ; any thoughts? > Perhaps there is a clever workaround, but I wonder if the best solution isn't to build dual versions of the extensions, one for Numeric and one for numarray if both are present (and this would also solve the win32 issue by distributing both). I think setup.py could be setup to do this, and a mechanism for a module that uses these to use whichever is selected by the user to pick up the right sharable (e.g., _numarray_mycext.so vs _Numeric_mycext.so). It's not elegant, but it should be robust. Todd and I did talk about if there was a way to make numarray arrays compatable at the binary level; perhaps, but I suspect it involves a lot work and I'm not sure it will eliminate all issues. So do you want us to try to come up with a an example setup.py to do this? Perhaps Todd will have some other ideas. Perry |
From: John H. <jdh...@ac...> - 2004-05-14 12:58:15
|
The new transformation module I've been working on is implemented in extension code. It offers a couple of important benefits, namely speed and generality (affines, nonseparable xy transformations). It's not in CVS yet because I'm still ironing out the details. I have two methods for operating over sequences of x and y, seq_x_y and numerix_x_y. The first uses the python sequence API and the second uses the numerix api. I expect the latter will be a good bit faster for long lines, since it doesn't have the python object type coercion to deal with, but I haven't profiled it. But there is a gotcha. When I compile the code, I use flag in setup.py to indicate whether to compile with Numeric or numarray. This sets a flag and that is used in the transforms module (and the image module) that will import arrayobject.h from either Numeric or numarray. A problem can arise if someone compiles with one and uses a different setting in ~/.matplotlibrc. I compiled the module with Numeric but used numarray in my matplotlibrc. The transformation went fine, presumably thanks to the numarray compatibility layer. I passed the transformed arrays off to one of the backends, which does from matplotlib.numerix import Int16 y = int(self.height) - y.astype(Int16) and got a ValueError: type must be either a 1-length string, or python type object clearly because of the difference between numpy and numarray type args. Is there a clever workaround for this problem? It doesn't affect any of the agg or PS backends. GTK and GD both need to convert their arrays to ints before passing them on to their respective renderers. One solution is to do the conversion in list comps y = [ int(self.height-val) for val in y] which obviously implies a performance hit but probably a bearable one given the other speedups that the new transformation module implies and that users have an option to use GTKAgg instead of GTK and Agg instead of GD for optimal performance. Another question is win32, where the user doesn't have the choice at compile time. If we compile in numpy for win32, the user's numarrays will be transformed into numpys at render time, but this won't affect the user arrays (unlike in scipy where the user is getting the return values) so I don't see it as a big deal. I think trying to compile in both or supplying alternate binaries is doable but may not be worth the maintenance and complexity. In any case, there are a couple of readers here who know a bit more about numarray and numeric than I do <wink> ; any thoughts? JDH |
From: Karthikesh R. <ka...@ja...> - 2004-05-14 06:38:20
|
Hi John, thanks, it seems to work now atleast .. warm regards karthik ----------------------------------------------------------------------- Karthikesh Raju, email: ka...@ja... Researcher, http://www.cis.hut.fi/karthik Helsinki University of Technology, Tel: +358-9-451 5389 Laboratory of Comp. & Info. Sc., Fax: +358-9-451 3277 Department of Computer Sc., P.O Box 5400, FIN 02015 HUT, Espoo, FINLAND ----------------------------------------------------------------------- On Thu, 13 May 2004, John Hunter wrote: > >>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes: > > Karthikesh> Hi John, Looks like in the previous mail, i had set > Karthikesh> the build numarray on, now i removed that flag, and > Karthikesh> the installation went on smooth, and i could > > Karthikesh> 1) pygtk, 2) gtk, and 3) matplotlib > > Karthikesh> things went smooth so far, and i run most of the > Karthikesh> examples bearing some. Now i will try to set things > Karthikesh> to auto slowly and try the rest. > > > Great! Start with agg, then image, then gtkagg, and that may be all > you need. Unless you want to use matplotlib interactively from the > shell, in which case tkagg is your best bet. > > Karthikesh> BTW: the following were the developmental packages > Karthikesh> that i needed here: (At work our sys's have not > Karthikesh> installed any of the developmental packages) > > Thanks for the list! I'll put it on the web site. > > JDH > > |
From: Jean-Baptiste C. <jc...@de...> - 2004-05-13 15:24:47
|
S=E6ll ! I was simply planning to be able to move between the default positions 'upp= er right', 'upper left', etc But I believe I can use _offset. However it did not produce much effect I have defined the legend the following way: canvas.leg=3DFigure.legend(canvas.figure,tuple([i[1] for i in d]),tuple([i[= 0] for i in d]),'best') And then when I toggle a button I apply the following move with the canvas = object, which is just a test offset def toggle_legend(self, event): """ Toggle the label in the legend button=20 between Upper Right and Upper Left """ =20 if self.Legend_button.get_active()=3D=3D1: self.Legend_button.set_label("Upper Right") else: self.Legend_button.set_label("Upper Left") self.leg._offset(0.1,0.56) self.draw() =20 return When I toggle the button, the label changes, but the legend is unmoved. Am I missing something ?=20 Takk Jean-Baptiste On Thu, 13 May 2004 05:20:28 -0500 John Hunter <jdh...@ni...> wrote: > >>>>> "Jean-Baptiste" =3D=3D Jean-Baptiste Cazier <jc...@de...> wri= tes: >=20 > Jean-Baptiste> S_ll ! I would like to be able to move my > Jean-Baptiste> Figure.legend Because the optimal position of the > Jean-Baptiste> legend on my figure is not always the same, I added > Jean-Baptiste> a button to the navigation toolbar to give the suer > Jean-Baptiste> a chance to choose the position of the legend I > Jean-Baptiste> knwo that I can get a handle on my first legend > Jean-Baptiste> drawing, but how can I just modify its location ? > Jean-Baptiste> Is there a move_location method for the > Jean-Baptiste> Figure.legend ? >=20 > There is currently no "move to" location, but there is an offset > method where you can supply a deltxa, deltay in relative sizes, in > your case fractions of the figure width and height. So if you wanted > to move the legend 5% of the figure width to the right and 10% of the > figure height up, you can call >=20 > leg._offset(0.05, 0.10) >=20 > The leading underscore means that this method was intended for > internal use, and may change in future releases, but you can try it > and see if it works for you. If it does, I can probably make it > a public method for the next release. >=20 > As always you'll need to call canvas.draw after setting the new legend > location. > =20 >=20 > JDH --=20 ----------------------------- Jea...@de... Department of Statistics deCODE genetics Sturlugata,8 570 2993 101 Reykjav=EDk |
From: John H. <jdh...@ac...> - 2004-05-13 13:38:01
|
>>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes: Karthikesh> Hi John, Looks like in the previous mail, i had set Karthikesh> the build numarray on, now i removed that flag, and Karthikesh> the installation went on smooth, and i could Karthikesh> 1) pygtk, 2) gtk, and 3) matplotlib Karthikesh> things went smooth so far, and i run most of the Karthikesh> examples bearing some. Now i will try to set things Karthikesh> to auto slowly and try the rest. Great! Start with agg, then image, then gtkagg, and that may be all you need. Unless you want to use matplotlib interactively from the shell, in which case tkagg is your best bet. Karthikesh> BTW: the following were the developmental packages Karthikesh> that i needed here: (At work our sys's have not Karthikesh> installed any of the developmental packages) Thanks for the list! I'll put it on the web site. JDH |
From: Karthikesh R. <ka...@ja...> - 2004-05-13 13:34:09
|
Hi John, Looks like in the previous mail, i had set the build numarray on, now i removed that flag, and the installation went on smooth, and i could 1) pygtk, 2) gtk, and 3) matplotlib things went smooth so far, and i run most of the examples bearing some. Now i will try to set things to auto slowly and try the rest. BTW: the following were the developmental packages that i needed here: (At work our sys's have not installed any of the developmental packages) audiofile-devel-0.2.3-6.i386.rpm gtk2-devel-2.2.1-4.i386.rpm esound-devel-0.2.28-4.i386.rpm gtk+-devel-1.2.10-25.i386.rpm freetype-2.1.3-6.i386.rpm imlib-devel-1.9.13-12.i386.rpm freetype-devel-2.1.3-6.i386.rpm ORBit-devel-0.5.17-7.i386.rpm freetype-utils-2.1.3-6.i386.rpm pygtk2-1.99.16-8rh9.i386.rpm glib-devel-1.2.10-10.i386.rpm pygtk2-devel-1.99.16-8rh9.i386.rpm gnome-libs-devel-1.4.1.2.90-32.i386.rpm pygtk2-libglade-1.99.16-8rh9.i386.rpm Many had circular dependences, and hence the requirement. Thankx, warm regards karthik ----------------------------------------------------------------------- Karthikesh Raju, email: ka...@ja... Researcher, http://www.cis.hut.fi/karthik Helsinki University of Technology, Tel: +358-9-451 5389 Laboratory of Comp. & Info. Sc., Fax: +358-9-451 3277 Department of Computer Sc., P.O Box 5400, FIN 02015 HUT, Espoo, FINLAND ----------------------------------------------------------------------- On Thu, 13 May 2004, John Hunter wrote: > >>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes: > > Since you are facing multiple issues, let's try and get the simplest > build working and then add stuff in. First though, it would be > helpful if you told me what devel rpms you needed to install so I > recommend these on the web page to other users. BTW, the two pages > most relevant for you with installation information are > http://matplotlib.sf.net/installing.html and > http://matplotlib.sf.net/backends.html. Make sure you give these a > good read. > > From reading your email, I see that you are installing everything to > your home dir, is that right? > > Step 1: start with a clean matplotlib src tree. I don't want to try > and work with the one where you have hardcoded information in the > code because then I don't know what is going on. Just untar the > tar.gz file in a new dir and start cleanly > > Step 2: Edit setup.py and turn all the BUILD flags off, except for > BUILD_FT2FONT. Let's try and get a working base install and then deal > with getting the extension code compiled. > > Step 3: Edit setupext.py and add any non-standard base dirs in which > you have installed stuff (eg /home/you/usr, /home/you/usr/local') to > the basedirs dictionary at the top of that file. Your platform is > linux2. > > Step 4: Install matplotlib with > python setup.py install > > Step 5: If the build doesn't finish cleanly (the only reason I can > think it would fail is if you don't get ft2font built properly. > This package requires lib freetype so make you have the freetype and > freetype-devel libs installed. It also requires libz so make sure > you have zlib and zlib-devel installed. If you have installed these > to a nonstandard place, make sure you add the basedir to setupext > basedirs. > > Step 6: OK, I'm assuming you have a clean install at this point. If > you installed with a non-standard prefix, you need to set your > MATPLOTLIBDATA environment variable. This data should point to the > dir that contains, for example, all the Vera*.ttf files. Eg, > /your/install/prefix/share/matplotlib. If you add this to your rc > file, make sure you resource your rc or open a new shell. > > Step 7: At this point, if you have numarray and pygtk installed > (1.99.16 or later), you should be able to import matplotlib. Open up > python shell and make sure you can do > > >>> import pygtk > >>> pygtk.require('2.0') > >>> import gtk > >>> import numarray > >>> import matplotlib > > If not, let us know what error you are getting. You should now be > able to run python simple_plot.py -dGTK > > > Step 8: Edit setup.py and add the other build flags back in. You can > set the ones you want to build to 'auto', which will try and build > an extension if the python dependencies are found. If you still > have problems with arrayobject.h, let me know. You can add the > include path to that file in the build_image method in setupext.py > by doing > > module.include_dirs.append('/your/path/to/numerix/headers') > > ie, /home/karthik/usr/include/python/numarray > > > We do want to improve the build process for people who have stuff in > non-default locations, and it would be very helpful for us if you tell > us explicitly what you had to add and change in the steps above so we > can incorporate as much as possible into the default. > > Good luck! > JDH > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > |
From: John H. <jdh...@ac...> - 2004-05-13 13:15:14
|
>>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes: Karthikesh> Ofcourse, numarray/arrayobject.h is at Karthikesh> /home/karthik/usr/include/python/numarray Karthikesh> What should i do next ? Well it looks like you did not turn off the BUILD_IMAGE flag - set BUILD_IMAGE = 0 and all the other BUILD_* flags except FT2FONT to 0. The instructions for how to handle arrayobject are included later in my instructions, but let's stay on target! Note that I did give you the wrong path for arrayobject in my previous email. When you get to step 8, I'm fairly certain you will need module.include_dirs.append('/home/karthik/usr/include/python') JDH |
From: John H. <jdh...@ac...> - 2004-05-13 13:04:59
|
>>>>> "Nils" == Nils Wagner <nw...@me...> writes: Nils> Now python setup.py build works fine. However Nils> python setup.py install Nils> as root failed with the following messages Nils> Xlib: connection to ":0.0" refused by server Xlib: No Nils> protocol specified Nils> Traceback (most recent call last): File "setup.py", line 75, Nils> in ? try: import gtk File Nils> "/usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py", Nils> line 43, in ? from _gtk import * RuntimeError: could not Nils> open display Nils> Any hint is appreciated A couple of areas in the build process currently require an X connection. This should probably be fixed. Are you building on a local or remote machine? * If you are building on a remote machine, you need to set the display or use automatic X forwarding with ssh -X. * If you are building on a local machine, I think the problem is that when you go to install you are root and root doesn't have access to the display. You can verify this by trying to do root> xterm& and see if you can get a window to pop up. If not, you need to tell the windowing system to allow connections from root. Unix gurus please advise here. Something like user> python setup.py build user> xhost + user> su root> python setup.py install root> exit user> xhost - Let me know! JDH |
From: John H. <jdh...@ac...> - 2004-05-13 12:54:34
|
>>>>> "Nils" == Nils Wagner <nw...@me...> writes: Nils> /home/nwagner> pkg-config --libs pygtk-2.0 -L/opt/gnome/lib Nils> -lgobject-2.0 -lglib-2.0 Nils> /home/nwagner> pkg-config --libs gtk+-2.0 Nils> -Wl,--export-dynamic -L/opt/gnome/lib -lgtk-x11-2.0 Nils> -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 Nils> -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl Nils> -lglib-2.0 Well that's interesting because pkg-config is doing it's job and finding -L/opt/gnome/lib. You should verify that that flag is indeed being added on the compile line that is failing but it should be so I don't think this is your problem. In and case, could you post that line and the first couple of error messages you get. Can anyone think of any reason why you would get a linker failure to find -lgobject-2.0 if the compiler gets -L/opt/gnome/lib and the following exist /opt/gnome/lib/libgobject-2.0.a /opt/gnome/lib/libgobject-2.0.la /opt/gnome/lib/libgobject-2.0.so Is this some sun os weirdness? JDH |
From: Nils W. <nw...@me...> - 2004-05-13 12:53:02
|
Dear experts, I have added the following entries in setupext.py (i.e. '/opt/gnome' basedir = { 'win32' : ['win32_static',], 'linux2' : ['/usr','/opt/gnome',], 'linux' : ['/usr','/opt/gnome',], 'darwin' : ['/usr/local', '/sw'], 'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',], } Now python setup.py build works fine. However python setup.py install as root failed with the following messages Xlib: connection to ":0.0" refused by server Xlib: No protocol specified Traceback (most recent call last): File "setup.py", line 75, in ? try: import gtk File "/usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py", line 43, in ? from _gtk import * RuntimeError: could not open display Any hint is appreciated Nils |