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
(7) |
2
|
3
|
4
(1) |
5
|
6
(3) |
7
(1) |
8
(5) |
9
(15) |
10
(15) |
11
(6) |
12
(7) |
13
|
14
(3) |
15
(10) |
16
(11) |
17
(17) |
18
(4) |
19
(6) |
20
|
21
(1) |
22
(5) |
23
(4) |
24
|
25
|
26
(7) |
27
(2) |
28
(4) |
29
(9) |
30
(11) |
|
|
|
|
Thanks for your feedback. I ran it with --verbose-helpful, and indeed I got some helpful messages (see below). I'll have to remember that in future. You are right, one module is loading the TKAgg backend, and the other is loading the GTK backend. The reason I have this in my modules is that I have one module A which is intended to be very general purpose, but has a couple of hooks to do plots. Module A doesn't care which backend it uses, and at the moment it uses the matplotlib.matlab interface because that's what I knew when I wrote it. Module B is a more specific application, which was using matlab calls, but I found I had to convert it to use GTK and the matplotlib API because I call it from application C which has a GUI window using GTK and glade. Summary: module A: general purpose, matlab API, no hardcoded backend module B: more specialised, matplotlib API, GTK backend, explicit GTK window management app C: more specialised, no matplotlib or matlab, GTK & glade GUI, functions from modules A and B used in callback threads I don't really want to force module A to use GTK, because TKAgg (or whatever's in .matplotlibrc) is more likely to work for other users on other machines. So for the moment I can get by, if I import module A after module B. But maybe there is some nice way to do things that I'm missing. Perhaps I can convert module A to use the matplotlib API but still not specify the backend, and it will still work standalone and also start playing nicely with module B and app C. I'll have a play with it when I get some time. Here is the output from "python frog.py --verbose-helpful": $ python frog.py --verbose-debug matplotlib data path c:\Python23\share\matplotlib loaded rc file c:\Python23\share\matplotlib\.matplotlibrc matplotlib version 0.64 verbose.level debug interactive is False numerix Numeric 23.3 font search path ['c:\\Python23\\share\\matplotlib', '/usr/share/fonts/msttf'] loaded ttfcache file M:\home\mra\.ttffont.cache matplotlib data path c:\Python23\share\matplotlib loaded rc file c:\Python23\share\matplotlib\.matplotlibrc matplotlib version 0.64 verbose.level debug interactive is False backend TkAgg version 8.4 Could not load matplotlib icon: Couldn't recognize the image file format for file 'c:\Python23\share\matplotlib\matplotlib.svg' Traceback (most recent call last): File "frog.py", line 6, in ? embedding_in_gtk2_mra.plotme() File "M:\home\My Documents\My Downloads\matplotlib-0.64\matplotlib-0.64\exampl es\embedding_in_gtk2_mra.py", line 43, in plotme toolbar = NavigationToolbar(canvas, win) File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 963, in __init__ NavigationToolbar2.__init__(self, canvas) File "C:\Python23\Lib\site-packages\matplotlib\backend_bases.py", line 786, in __init__ self._init_toolbar() File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 1028, in _init_toolbar self._init_toolbar2_4() File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 1091, in _init_toolbar2_4 parent=self.win,) File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 1423, in __init__ self.IMAGE_FORMAT = matplotlib.backends.backend_mod.IMAGE_FORMAT AttributeError: 'module' object has no attribute 'IMAGE_FORMAT' Cheers, Matthew. John Hunter wrote: >>>>>>"matthew" == matthew arnison <ma...@ca...> writes: > > > matthew> Oh dear. I'm going to take another u-turn, and say I hit > matthew> this IMAGE_FORMAT attribute glitch again. > > Try running your script with --verbose-helpful or --verbose-debug and > report the output. That way we can see what is happening behind the > scenes. > > matthew> To atone for my reversals, I have isolated a test case, > matthew> and I attach sample code. It seems to be triggered by > matthew> importing matplotlib.matlab in one module, and importing > matthew> matplotlib backend stuff directly in another module. > > matthew> Running frog.py gives: > matthew> line 1423, in __init__ self.IMAGE_FORMAT = > matthew> matplotlib.backends.backend_mod.IMAGE_FORMAT > matthew> AttributeError: 'module' object has no attribute > matthew> 'IMAGE_FORMAT' > > Fernando added the backend_mod to matplotlib.backends.__init__.py -- > perhaps he has some insight into what is going on. > > matthew> As commented in the code, changing the order of the > matthew> import statements in frog.py avoids the bug. Or using the > matthew> workaround I mentioned below. > > matthew> Hmmm. Now I remember an email from John Hunter saying > matthew> that pythonic matplotlib should not be mixed with the > matthew> matlab interface. Maybe this glitch is an artefact of > matthew> that. It does mean however that all my modules have to > matthew> use one API or the other. > > Yes, this is basically undefined. When using the API, you control > figure canvases, windows, backends, etc, independently. When you > import matplotlib.matlab, it parses your rc file (or not finding it > falls back on a default) and may try and load a different backend. > Since IMAGE_FORMAT is only used in some backends, my guess is you are > seeing a backend conflict. Running --verbose-helpful should give you a > clue about which backends matplotlib is loading. > > Note there are scant few features in the matlab interface that you > can't access directly from the API. There is no compelling reason to > mix them, save laziness, and as you are finding, it doesn't really > save you any time. If you want to use something from the matlab > interface and aren't sure how to do it from the API, open up matlab.py > and take a look at how that function does it. A large number if not > the majority of matlab interface functions simply forward their calls > on to the current axes. > > JDH
Hi All, Can anyone tell me how to change the size of the legend produced by matlab.legend independently of my axis tick labels? lh=legend(['a','b','c'],loc=4,fontsize=8) doesn't work and there seems to be nothing in the lh object that would help. Cheers, Cory
>>>>> "Chris" == Chris <bi...@Fu...> writes: Chris> Dear John, I see your points. However, after I changed to Chris> using add_artist. This is still nothing on the canvas. I Chris> think that there is some problem with the draw function of Chris> my arrow class. I have no idea what else should be Chris> there. At the moment, only one call in my case as below. Chris> def draw(self, renderer): self._stem.draw(renderer) Chris> Could u tell what else should be called? Your drawing function looks fine. Could this be a problem with axes limits. Make sure the x and y limits are set properly with the xlim, ylim or axis commands. The limits are normally autoscaled by calling plot, but you are not using it so you have to take care that the limits are set. After you get a working prototype, I can help you with the autoscaling part. If this doesn't fix your problem, email me your matlab.py, axes.py and test code as attachments off-list and I'll take a look. JDH
Darren Dale wrote: > Matlab also returns one object- the varargout cell array which is > similar to Python's list or tuple. You write a function, and pack > varargout with nargout results: [a,b]=matlabfun(). I haven't used Matlab for a while, and not a newer version than 5.*, but IIRC, while the above notation looks, like you are returning a cell array, you could not call that fun with a single return argument. Perhaps that's changed, in which case you shouldn't use nargout in Matlab either! Anyway, my main point was that kludging a nargout implementation in python was not a good idea. I'd much rather see matplotlib be pythonesque than matlabesque. Perhaps my goals are different than others, but I use Python, rather than Matlab, largely because I like the language better. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
Dear John, I see your points. However, after I changed to using add_artist. This is still nothing on the canvas. I think that there is some problem with the draw function of my arrow class. I have no idea what else should be there. At the moment, only one call in my case as below. def draw(self, renderer): self._stem.draw(renderer) Could u tell what else should be called? Best regards, Chris John Hunter wrote: >>>>>>"Chris" == Chris <bi...@Fu...> writes: > > > Chris> I tried with what you suggested to make an Arrow class. To > Chris> begin with, I only put an Line2D instance. I searched for > Chris> table stuff in axes.py, matlab.py to make the arrow > Chris> importable from matplotlib.matlab. Then I also try a very > Chris> very simple demo and I expect to see a simple > Chris> line. However, I can not see it. Could someone tell me what > Chris> is the problem. Here is my very very rudimental codes. > > Nowhere in your code do you actually draw the arrows in self.arrows. > In Axes.draw you would need to do > > for arrow in self.arrows: > arrow.draw(renderer) > > And this should work. > > However, you can avoid all the overhead of add_arrow, and keeping a > list of arrows in self.arrows simply by doing > > > def arrow(self, x, y, *args, **kwargs): > a = Arrow(x,y, *args, **kwargs) > self.add_artist(a) > ^^^ > return a > > Ie, call add_artist which is a generic method for adding artists to > the axes. > > Hope this helps, > JDH > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: InterSystems CACHE > FREE OODBMS DOWNLOAD - A multidimensional database that combines > robust object and relational technologies, making it a perfect match > for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>>>>> "Chris" == Chris <bi...@Fu...> writes: Chris> I tried with what you suggested to make an Arrow class. To Chris> begin with, I only put an Line2D instance. I searched for Chris> table stuff in axes.py, matlab.py to make the arrow Chris> importable from matplotlib.matlab. Then I also try a very Chris> very simple demo and I expect to see a simple Chris> line. However, I can not see it. Could someone tell me what Chris> is the problem. Here is my very very rudimental codes. Nowhere in your code do you actually draw the arrows in self.arrows. In Axes.draw you would need to do for arrow in self.arrows: arrow.draw(renderer) And this should work. However, you can avoid all the overhead of add_arrow, and keeping a list of arrows in self.arrows simply by doing def arrow(self, x, y, *args, **kwargs): a = Arrow(x,y, *args, **kwargs) self.add_artist(a) ^^^ return a Ie, call add_artist which is a generic method for adding artists to the axes. Hope this helps, JDH
I tried with what you suggested to make an Arrow class. To begin with, I only put an Line2D instance. I searched for table stuff in axes.py, matlab.py to make the arrow importable from matplotlib.matlab. Then I also try a very very simple demo and I expect to see a simple line. However, I can not see it. Could someone tell me what is the problem. Here is my very very rudimental codes. ----------------------------------------------------------------- arrow.py from artist import Artist from lines import Line2D from patches import RegularPolygon class Arrow(Artist): """ An arrow with an triangular head . """ def __init__(self, xdata=None, ydata=None, *args, **kwargs): Artist.__init__(self) print xdata, ydata self._stem = Line2D(xdata, ydata, *args, **kwargs) def draw(self, renderer): self._stem.draw(renderer) ------------------------------------------------------------ in file axes.py in function cla add: self.arrows = [] --------------------------- def add_arrow(self, a): 'Add an arrow instance to the list of axes arrows' self._set_artist_props(a) self.arrows.append(a) def arrow(self, x, y, *args, **kwargs): a = Arrow(x,y, *args, **kwargs) self.add_arrow(a) return a ------------------------------------------------------------- in file matlab.py add two tring for importing arrow ------------------------------------------------------------- arrow_demo.py from matplotlib.matlab import * x = [0,1] y = [0,1] arrow(x,y, color='b',linestyle='-') show() ------------------------------------------------------------- Best regards, Chris John Hunter wrote: > I recommend creating an arrow class, derived from matplotlib.artist.Artist, that > contains a matplotlib.lines.Line2D for the arrow stem and a > matplotlib.patches.RegularPolygon with numVertices=3 for the arrow > head. You can control the rotation of the arrowhead with the > orientation argument. > > Once you have this class so defined, you can add it instances of it to > the axes with ax.add_artist(arrow). > > I'll be happy to help out with a prototype if you have trouble. Take > a look at matplotlib.table.Cell, which John Gill wrote to support > tables. You can use this as a simple model for how to write new > artists (things that draw into a figure) composed of other artists. > > It would be nice to have a fancy arrow class, that supported text > labeling, at the base, along the stem and at the arrowhead. You could > also consider a more sophisticated polygon other than a triangle for > the arrowhead. > > Finally, if you needed to draw *a lot of arrows*, order of a thousand > or more (eg for direction fields), a > matplotlib.collections.PolygonCollection would be the way to go for > efficiency. > > JDH > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>>>>> "matthew" == matthew arnison <ma...@ca...> writes: matthew> Oh dear. I'm going to take another u-turn, and say I hit matthew> this IMAGE_FORMAT attribute glitch again. Try running your script with --verbose-helpful or --verbose-debug and report the output. That way we can see what is happening behind the scenes. matthew> To atone for my reversals, I have isolated a test case, matthew> and I attach sample code. It seems to be triggered by matthew> importing matplotlib.matlab in one module, and importing matthew> matplotlib backend stuff directly in another module. matthew> Running frog.py gives: matthew> line 1423, in __init__ self.IMAGE_FORMAT = matthew> matplotlib.backends.backend_mod.IMAGE_FORMAT matthew> AttributeError: 'module' object has no attribute matthew> 'IMAGE_FORMAT' Fernando added the backend_mod to matplotlib.backends.__init__.py -- perhaps he has some insight into what is going on. matthew> As commented in the code, changing the order of the matthew> import statements in frog.py avoids the bug. Or using the matthew> workaround I mentioned below. matthew> Hmmm. Now I remember an email from John Hunter saying matthew> that pythonic matplotlib should not be mixed with the matthew> matlab interface. Maybe this glitch is an artefact of matthew> that. It does mean however that all my modules have to matthew> use one API or the other. Yes, this is basically undefined. When using the API, you control figure canvases, windows, backends, etc, independently. When you import matplotlib.matlab, it parses your rc file (or not finding it falls back on a default) and may try and load a different backend. Since IMAGE_FORMAT is only used in some backends, my guess is you are seeing a backend conflict. Running --verbose-helpful should give you a clue about which backends matplotlib is loading. Note there are scant few features in the matlab interface that you can't access directly from the API. There is no compelling reason to mix them, save laziness, and as you are finding, it doesn't really save you any time. If you want to use something from the matlab interface and aren't sure how to do it from the API, open up matlab.py and take a look at how that function does it. A large number if not the majority of matlab interface functions simply forward their calls on to the current axes. JDH
Oh dear. I'm going to take another u-turn, and say I hit this IMAGE_FORMAT attribute glitch again. To atone for my reversals, I have isolated a test case, and I attach sample code. It seems to be triggered by importing matplotlib.matlab in one module, and importing matplotlib backend stuff directly in another module. Running frog.py gives: Traceback (most recent call last): File "frog.py", line 4, in ? embedding_in_gtk2_mra.plotme() File "M:\home\My Documents\My Downloads\matplotlib-0.64\matplotlib-0.64\examples\embedding_in_gtk2_mra.py", line 39, in plotme toolbar = NavigationToolbar(canvas, win) File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 963, in __init__ NavigationToolbar2.__init__(self, canvas) File "C:\Python23\Lib\site-packages\matplotlib\backend_bases.py", line 786, in __init__ self._init_toolbar() File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 1028, in _init_toolbar self._init_toolbar2_4() File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 1091, in _init_toolbar2_4 parent=self.win,) File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 1423, in __init__ self.IMAGE_FORMAT = matplotlib.backends.backend_mod.IMAGE_FORMAT AttributeError: 'module' object has no attribute 'IMAGE_FORMAT' As commented in the code, changing the order of the import statements in frog.py avoids the bug. Or using the workaround I mentioned below. Hmmm. Now I remember an email from John Hunter saying that pythonic matplotlib should not be mixed with the matlab interface. Maybe this glitch is an artefact of that. It does mean however that all my modules have to use one API or the other. Cheers, Matthew. matthew arnison wrote: > 2. I was getting errors that the > matplotlib.backends.backend_mod.IMAGE_FORMAT attribute was not found, > during toolbar initialization. I put in a workaround. > > works with matplotlib 0.63: > > import matplotlib > matplotlib.use('GTK') > > from matplotlib.backends.backend_gtk import FigureCanvasGTK > from matplotlib.backends.backend_ps import FigureCanvasPS > from matplotlib.backends.backend_gtk import NavigationToolbar2GTK as > NavigationToolbar > > using matplotlib 0.64: > > import matplotlib > matplotlib.use('GTK') > from matplotlib.backends import backend_gtk > matplotlib.backends.backend_mod = backend_gtk > > from matplotlib.backends.backend_gtk import FigureCanvasGTK > from matplotlib.backends.backend_ps import FigureCanvasPS > from matplotlib.backends.backend_gtk import NavigationToolbar2GTK as > NavigationToolbar > > This style was cribbed from matplotlib examples and / or emails on this > list. > > Cheers, > Matthew.
John Hunter wrote: >>>>>>"Chris" == Chris Barker <Chr...@no...> writes: >>>>>> >>>>>> > > > Chris> no, I was a bit wrong. Python functions always return one > Chris> object, and when it appears that you are returning multiple > Chris> objects, you are really returning a single tuple with > Chris> multiple objects in it. Have I got it right this time? > >Sounds right to me. Your answer does point to the danger of using >nargout in python > > ret = somefunc() > i,j = ret > >If somefunc is relying on nargout, it will botch it. > >I think the only sane use for nargout in python is in auto-conversion >scripts, and then with appropriate warnings. > >Thanks said, I would still like to have it, for that reason. > > Matlab also returns one object- the varargout cell array which is similar to Python's list or tuple. You write a function, and pack varargout with nargout results: [a,b]=matlabfun().
Well it works now. For other reasons I downgraded to 0.63 and upgraded again to 0.64. As part of this I found I had to manually wipe not only Python23/Lib/site-packagaes/matplotlib but also Python23/share/matplotlib to avoid errors (e.g. an ImportError: cannot import artist from Artist). But now I don't need that workaround to avoid the IMAGE_FORMAT error. examples/embedding_in_gtk2.py works fine too, after patching in the toolbar = NavigationToolbar(canvas, win) API change. I'm sorry for the confusion. Cheers, Matthew. On 2004年11月10日, Steve Chaplin wrote: > On Tue, 2004年11月09日 at 12:24, matthew arnison wrote: > > 2. I was getting errors that the > > matplotlib.backends.backend_mod.IMAGE_FORMAT attribute was not > > found, during toolbar initialization. I put in a workaround. > > Is this happening when using the classes directly rather than using the > matlab interface? Are you doing something similar to the example > "embedding_in_gtk2.py" - that works OK for me. > Could you provide a minimal example to demonstrate this. > > Steve