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
(11) |
2
(2) |
3
(2) |
4
|
5
(1) |
6
(6) |
7
(9) |
8
(5) |
9
(1) |
10
(1) |
11
(1) |
12
(7) |
13
(6) |
14
(3) |
15
(1) |
16
(10) |
17
(1) |
18
(2) |
19
(3) |
20
(14) |
21
(14) |
22
(18) |
23
(5) |
24
(5) |
25
(1) |
26
(22) |
27
(5) |
28
(21) |
29
(25) |
30
(3) |
|
>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes: Peter> Hi: I attach a pcolor plot. I would like to get rid of the Peter> areas outside the larger circle and inside the smaller Peter> circle. Ideally I would like them to be white. Currently I Peter> create my plot using pcolor and then plot *lots* of white Peter> circles (for the inside) and lines (for the outside) on Peter> top, to get rid of the unwanted areas. This works but I Peter> wonder whether there is a better/faster solution. I would Peter> imagine I could set the values corresponding to the Peter> unwanted areas to some particular color before I call Peter> pcolor, but the issue is that I want those ares to be white Peter> (or other color not included in the standard palette which Peter> is used for plotting the area inside the annulus). Can this Peter> be done? Inside the circle is easy - just set the facecolor of the circle to be white 'w', or whatever rgb tuple you want. How are you creating the circles, with plot, scatter, or instantiating your own Circle instances? Outside the circle requires implementing general clipping, which will be done but I can't say how soon right now. What backend are you using? The circles don't look antialiased so I'm guessing not agg. agg and postscript are probably the best bets for getting general clipping support first. Another question: is there a reason you are using pcolor rather than imshow? imshow will give you the same result with interpolation and dramatic performance benefits. Since you aren't using faceted shading or otherwise tweaking the pcolor rectangles, you don't gain anything by using pcolor unless you need a backend that doesn't support imshow yet (gd?) Peter> Another question is in regards to showing tics in pcolor Peter> plots. In my "legend" on the right, I would like them to be Peter> visible, but they get overwritten. I suppose I could plot Peter> each manually after I do pcolor; is it how this is meant to Peter> be done? This is an easy fix. Basically you just need to move the axis drawing to the end of the axes drawing code. Currently it is done before any before any lines or patches are drawn. Try replacing matplotlib.Axes._draw with the code below. I'll make a deal: if you contribute some code to produce the nice color legend you made, I'll try and implement general clipping! JDH def _draw(self, renderer, *args, **kwargs): "Draw everything (plot lines, axes, labels)" if not ( self.xaxis.viewlim.defined() and self.yaxis.viewlim.defined() ): self.update_viewlim() if self.axison: if self._frameon: self._axesPatch.draw(renderer) if self._image is not None: self._image.draw(renderer) for p in self._patches: p.draw(renderer) for line in self._lines: line.draw(renderer) for t in self._text: t.draw(renderer) self._title.draw(renderer) if 0: bbox_artist(self._title, renderer) # optional artists for a in self._artists: a.draw(renderer) if self._legend is not None: self._legend.draw(renderer) for table in self._tables: table.draw(renderer) if self.axison: self.xaxis.draw(renderer) self.yaxis.draw(renderer)
Hi: I attach a pcolor plot. I would like to get rid of the areas outside the larger circle and inside the smaller circle. Ideally I would like them to be white. Currently I create my plot using pcolor and then plot *lots* of white circles (for the inside) and lines (for the outside) on top, to get rid of the unwanted areas. This works but I wonder whether there is a better/faster solution. I would imagine I could set the values corresponding to the unwanted areas to some particular color before I call pcolor, but the issue is that I want those ares to be white (or other color not included in the standard palette which is used for plotting the area inside the annulus). Can this be done? Another question is in regards to showing tics in pcolor plots. In my "legend" on the right, I would like them to be visible, but they get overwritten. I suppose I could plot each manually after I do pcolor; is it how this is meant to be done? Thanks -- Peter Groszkowski Gemini Observatory Tel: +1 808 974-2509 670 N. A'ohoku Place Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA
Hello, I'm making simple plots with matplotlib, and I've tried the mathematical text stuff, but ylabel(r'$\alpha > \beta$') puts the text horizontally instead of vertically. Also, I don't get any effect using fontsize : xlabel(r'$\alpha > \beta$',fontsize=20) or xlabel(r'$\alpha > \beta$',fontsize=10) give the same thing. Thanks, YLD
>>>>> "Eric" == <er...@jo...> writes: Eric> I am trying to output a large number of pictures to files. I Eric> don't know the correct usage of figure() in this case, so my Eric> program end up devouring memory continuously. I tried to use Eric> the clear() method or del, but neither works. Or I didn't Eric> use right. I just ran this test script on my system: from matplotlib.matlab import * i = 0 while 1: i+=1 print 'Figure', i figure(1) plot([1,2,3]) savefig('somefig') close(1) The critical thing is to call close, otherwise you won't free the resources (figures are managed by a dictionary so there is a reference to them behind the scenes). To be safest, I would just reuse figure(1) each time and issue close(1) at the end of the loop. However, there is a smallish memory leak even when used correctly. On my system I went from about 6% memory usage to 18% in generating 3300 figures. Tracking it down will be a top priority, so I'll hopefully have a fix soon. 99% likelihood it's either in agg or ft2font. How many figures are you generating and what kind of memory loss are you seeing? If you use the idiom above, does the situation improve? JDH
Hi Todd, I changed the directory from matplotlib-0.53 and the problem with ft2font went away. Thanks, --Gerry Wiener Todd Miller wrote: >Hi Gerry, > >I just noticed a similar "failure" when I try to run matplotlib from the >root of the source tree, i.e. the directory matplotlib-0.53. I think >doing that (running from the root) causes Python to interpret the >matplotlib subdirectory (matplotlib-0.53/matplotlib) as a package and to >look for ft2font.so there rather than in site-packages/matplotlib. Try >cd'ing to some other directory. > >HTH, >Todd > > >On Wed, 2004年04月21日 at 15:47, Gerry Wiener wrote: > > >>I'm trying to run the first example in the tutorial but am running into >>an import problem: >> >>ActivePython 2.3.2 Build 231 (ActiveState Corp.) based on >>Python 2.3.2 (#1, Nov 6 2003, 09:47:20) >>[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >>> from matplotlib.matlab import * >>Traceback (most recent call last): >> File "<stdin>", line 1, in ? >> File "matplotlib/matlab.py", line 128, in ? >> from axes import Axes >> File "matplotlib/axes.py", line 10, in ? >> from axis import XTick, YTick, XAxis, YAxis >> File "matplotlib/axis.py", line 22, in ? >> from font_manager import FontProperties >> File "matplotlib/font_manager.py", line 38, in ? >> from matplotlib import ft2font >>ImportError: cannot import name ft2font >> >>I've built and installed the freetype2 library and the matplotlib >>installation cites: >> >>running install_lib >>copying build/lib.linux-i686-2.3/matplotlib/backends/_tkagg.so -> >>/d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/backends >>copying build/lib.linux-i686-2.3/matplotlib/backends/_backend_agg.so -> >>/d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/backends >>copying build/lib.linux-i686-2.3/matplotlib/ft2font.so -> >>/d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib >>copying build/lib.linux-i686-2.3/matplotlib/_image.so -> >>/d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib >> >>Not sure what's going wrong. Please respond to my email as well since >>I'm not a subscriber to the email list. >> >>Thanks, >> >>Gerry Wiener >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: IBM Linux Tutorials >>Free Linux tutorial presented by Daniel Robbins, President and CEO of >>GenToo technologies. Learn everything from fundamentals to system >>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >>_______________________________________________ >>Matplotlib-users mailing list >>Mat...@li... >>https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >>
>>>>> "Todd" == Todd Miller <jm...@st...> writes: Todd> Hi Gerry, I just noticed a similar "failure" when I try to Todd> run matplotlib from the root of the source tree, i.e. the Todd> directory matplotlib-0.53. I think doing that (running from Todd> the root) causes Python to interpret the matplotlib Todd> subdirectory (matplotlib-0.53/matplotlib) as a package and Todd> to look for ft2font.so there rather than in Todd> site-packages/matplotlib. Try cd'ing to some other Todd> directory. Oh yes, that is the very likely culprit. It needs to be a FAQ. Good thinking! JDH
Hello again, I am trying to output a large number of pictures to files. I don't know the correct usage of figure() in this case, so my program end up devouring memory continuously. I tried to use the clear() method or del, but neither works. Or I didn't use right. Willing to learn from any of you. Eric
Hi Gerry, I just noticed a similar "failure" when I try to run matplotlib from the root of the source tree, i.e. the directory matplotlib-0.53. I think doing that (running from the root) causes Python to interpret the matplotlib subdirectory (matplotlib-0.53/matplotlib) as a package and to look for ft2font.so there rather than in site-packages/matplotlib. Try cd'ing to some other directory. HTH, Todd On Wed, 2004年04月21日 at 15:47, Gerry Wiener wrote: > I'm trying to run the first example in the tutorial but am running into > an import problem: > > ActivePython 2.3.2 Build 231 (ActiveState Corp.) based on > Python 2.3.2 (#1, Nov 6 2003, 09:47:20) > [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> from matplotlib.matlab import * > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "matplotlib/matlab.py", line 128, in ? > from axes import Axes > File "matplotlib/axes.py", line 10, in ? > from axis import XTick, YTick, XAxis, YAxis > File "matplotlib/axis.py", line 22, in ? > from font_manager import FontProperties > File "matplotlib/font_manager.py", line 38, in ? > from matplotlib import ft2font > ImportError: cannot import name ft2font > > I've built and installed the freetype2 library and the matplotlib > installation cites: > > running install_lib > copying build/lib.linux-i686-2.3/matplotlib/backends/_tkagg.so -> > /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/backends > copying build/lib.linux-i686-2.3/matplotlib/backends/_backend_agg.so -> > /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/backends > copying build/lib.linux-i686-2.3/matplotlib/ft2font.so -> > /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib > copying build/lib.linux-i686-2.3/matplotlib/_image.so -> > /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib > > Not sure what's going wrong. Please respond to my email as well since > I'm not a subscriber to the email list. > > Thanks, > > Gerry Wiener > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Todd Miller <jm...@st...>
>>>>> "Gerry" == Gerry Wiener <ge...@uc...> writes: Gerry> I'm trying to run the first example in the tutorial but am Gerry> running into an import problem: Gerry> cannot import name ft2font I haven't seen this one before. Are you using matplotlib-0.53 (released today?) My first guess is you have two python's installed and are installing to one and running the other. I installed and tested the lastest matplotlib on a redhat 7.1 machine so I don't see any problems with your OS. After upgrading to 0.53, you can make sure you are actually using it by mother:~/tmp/matplotlib-0.53/examples> python Python 2.3 (#1, Aug 29 2003, 12:14:15) [GCC 3.2.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. Welcome to rlcompleter2 0.95 for nice experiences hit <tab> multiple times >>> import matplotlib >>> matplotlib.version '0.53' If this doesn't help, let me know what > ldd /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/ft2font.so reveals. John Hunter
I'm trying to run the first example in the tutorial but am running into an import problem: ActivePython 2.3.2 Build 231 (ActiveState Corp.) based on Python 2.3.2 (#1, Nov 6 2003, 09:47:20) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from matplotlib.matlab import * Traceback (most recent call last): File "<stdin>", line 1, in ? File "matplotlib/matlab.py", line 128, in ? from axes import Axes File "matplotlib/axes.py", line 10, in ? from axis import XTick, YTick, XAxis, YAxis File "matplotlib/axis.py", line 22, in ? from font_manager import FontProperties File "matplotlib/font_manager.py", line 38, in ? from matplotlib import ft2font ImportError: cannot import name ft2font I've built and installed the freetype2 library and the matplotlib installation cites: running install_lib copying build/lib.linux-i686-2.3/matplotlib/backends/_tkagg.so -> /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/backends copying build/lib.linux-i686-2.3/matplotlib/backends/_backend_agg.so -> /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/backends copying build/lib.linux-i686-2.3/matplotlib/ft2font.so -> /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib copying build/lib.linux-i686-2.3/matplotlib/_image.so -> /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib Not sure what's going wrong. Please respond to my email as well since I'm not a subscriber to the email list. Thanks, Gerry Wiener
>>>>> "Eric" == <er...@jo...> writes: Eric> Dear ones, I discovered Matplotlit only yesterday, and it's Eric> great. But I've got one problem. Since I am using the GTK Eric> backend, I have to use the show() function. But I have Eric> hundreds of figures and each to be written into a file. If I Eric> put the show() at the end of my program, the machine just Eric> can't handle it. If I put the show() in a loop, then I have Eric> close the hundreds of picture windows by hand. Is there a Eric> solution to this problem? Yes, you want to use the Agg backend for bulk pure image generation. You don't need to use show and no GUI pops up. You can specify Agg from the command line by doing > python myscript.py -dAgg Or from within your script by doing import matplotlib matplotlib.use('Agg') from matplotlib.matlab import * plot([1,2,3]) savefig('myfile') Agg provides PNG output, which in my opinion is superior to jpeg for line art. These issues are covered in the FAQ, especially "Can I just generate images without having a window popup?" http://matplotlib.sourceforge.net/faq.html You should probably also check out http://matplotlib.sourceforge.net/tutorial.html and http://matplotlib.sourceforge.net/backends.html Good luck! JDH
Dear ones, I discovered Matplotlit only yesterday, and it's great. But I've got one problem. Since I am using the GTK backend, I have to use the show() function. But I have hundreds of figures and each to be written into a file. If I put the show() at the end of my program, the machine just can't handle it. If I put the show() in a loop, then I have close the hundreds of picture windows by hand. Is there a solution to this problem? Also the Matplotlib I downloaded doesn't have the file libjpeg.dll in it. Wonder where can I get it. Looking forward to hearing some advices from you. Enjoy the day. Eric
What's new in matplotlib 0.53 Improved font manager and support Paul Barrett has thoroughly overhauled font support. FontTools and ttfquery are no longer required for font finding as matplotlib now has a completely freestanding freetype2 implementation and font finder. Among other things, this should enable you to specify fonts in your scripts and matplotlibrc file and generate consistent figures across backends and operating systems. The font finder algorithm and implementation are based on the W3C standard http://www.w3.org/TR/1999/REC-CSS1-19990111. See the font manager module documentation, the fonts documentation http://matplotlib.sf.net/fonts.html and the updated .matplotlibrc file for more details; please update your .matplotlibrc. Thanks Paul! Backend WXAgg Antigrain rendering to wxpython applications and figure windows. Now wx users have access to all the latest matplotlib functionality, including mathtext, antialised drawing, alpha blending and image support. Major and minor ticks Full support for major and minor ticks with a bevy of more intelligent tick locators supplied in the ticker module. Fully customizable and user definable tick locators and formatters. See major_minor_demo1.py and major_minor_demo2.py. The default tick labeler is much more intelligent is choosing good tick locations. See http://matplotlib.sf.net/matplotlib.ticker.html Date plots A new command a plot_date command for plotting date dependent data; see http://matplotlib.sf.net/screenshots.html#date_demo. Converters supplied in the dates module allow you to work with a variety of datetime instances. Custom date locators and formatters allow you to place major and minor ticks by minute, hour, weekday, month, year, etc, and use strftime format strings to format the ticks. See examples date_demo1.py and date_demo2.py. The dates documentation provides an overview and guide to with dates - see http://matplotlib.sf.net/matplotlib.dates.html. Ported image support to numarray and postscript backend The image module now works with Numeric or numarray, and now works in the postscript backend as well as GTKAgg, TkAgg, WXAgg, Agg, and GTK. Thanks to Todd Miller for the PS work! Changes to matplotlibrc Many features added to the default config file for font support, tkagg windowing in win32, and more. Please use the new file at http://matplotlib.sf.net/.matplotlibrc. By default, the installer will overwrite the existing file in the install path, so if you want to preserve your's, please move it to your HOME dir and set the environment variable if necessary. load and save commands Helper functions for loading and saving ASCII arrays. See load and save in the matlab interface. Two scales on the same axes Added some features to the axis and ticks to allow two plots with different scales on the "same" axes with different scales, ticks and labels on the left and right side of the x axis. To see why same is quoted, see examples/two_scales.py. finance module The finance module includes a function to fetch quotes from yahoo, to draw candlestick plots, and to draw vertical line plots for high-low range with open-close ticks to the left and right. I'm hoping that user contributions will make up the bulk of this module since I'm not a finance guy! See http://matplotlib.sf.net/screenshots.html#date_demo. http://matplotlib.sourceforge.net
>>>>> "Perry" == Perry Greenfield <pe...@st...> writes: Perry> While not common, it does happen. I'm reminded of a Perry> handbook that was produced here that generated an incorrect Perry> plot because of a clipping error. We didn't write that Perry> clipping software, but it was embarrasing nonetheless. It's Perry> worth some effort to get it right I think. Before wasting Perry> more discussion over it I guess I'd like to know which Perry> backends don't support generalized clipping for lines and Perry> polygons. I'll delve deeper into agg and find out what exactly is going. BTW, Maxim has revamped the antigrain site, added documentation, and released some new code. I'm obviously waiting until the dust settles on the next matlotlib release before upgrading (and upgrading matplotlib agg cvs will be a bit of a pain since many file names hanve changed). http://antigrain.com JDH
John Hunter writes: > In Srinath's case, we've asked the backend to plot, for example, a > line from (0,-50000), (0,100) and then clip to the (25,25) (75,75) > rectangle. I don't think the average backend (GTK, Agg) knows what to > do with this line since they expect bitmap/display coords; there are > no backend transformations - everything happens on the front end > (clearly there are pros and cons of this approach, see below). > Hmmm, I've always figured that true clipping works with arbitrary coordinates, that it does handle exactly the problem that Srinath reports; when it doesn't then the clipping algorithm is not really fully implemented. I'm almost certain that OpenGL handles this correctly and would be surprised if postscript didn't as well. Is it true that agg will only clip positive coordinates correctly? If so I'm surprised. Some GUIs may not, but I would have thought this is standard for any graphics system. On the other hand, I admit to the possibility of being completely wrong about this. I'll look up the postscript situation. You are much more familiar with agg than I am, though (particularly since agg documentation is not easily accessible). > With data clipping turned, the line class throws out the (0,-50000) > point as illegal. > > To fix this in the current framework, we have to identify line > segments in the x,y arrays which intersect the view port but with one > or more end points outside the viewlim, and then draw the appropriate > line through view port. This issue primarily arises for connected Tell me about it :-). I wrote a Python program to do just this for a Chaco/kiva/Tk backend. Messy but doable. Clipping polygons is way messier (many complex algorithms developed for that in the literature). Performance was ok so long as the original curve didn't get fragmented into too many segments. (Worst case: 100,000 points; alternating one point out of range positive and the next out of range negative). > points (line styles '-', '--', and '-.' ). For symbol lines, data > clipping already does the right thing, which is to throw the point > away. However, there are hypothetical wacky cases you can imagine > when you feel like being mean to matplotlib, like a 'o' circle marker > 5 million miles from the view limits with a 5 million and one mile > radius..... For connected lines, this could be very costly to > implement since we have to loop over potentially very long arrays; for > markers it would be worse. > This is a bad case. This is where you do need the polygon clipping algorithm. > Refactoring transforms to the backend would probably fix this > entirely. While non-trivial, this may be the best long term solution, > especially when we want to do things like line and patch collections > for efficient drawing of large numbers of objects. The two major > benefits of the current transform architecture are 1) it lets you > specify locations like 5 points to the left of the right y axes, and > have the transform automatically update in the presence of window > resizes, dpi changes, etc... Very nice when drawing ticks.... and 2) > backends only have to think about one coord system, display, which > makes it easier to implement a backend. > I'm not sure this is needed if all the important backends (i.e., Agg-based, postscript, svg, ...) support this capability. Users are warned that clipping doesn't work well for the other backends or the backend calls call clipping functions on their data points before calling the graphics primitives. > I'm not convinced that it is a terrible thing to have a policy that > matplotlib only plots line segments and markers whose vertices are in > the axes limits, but I'm open to being convinced. > While not common, it does happen. I'm reminded of a handbook that was produced here that generated an incorrect plot because of a clipping error. We didn't write that clipping software, but it was embarrasing nonetheless. It's worth some effort to get it right I think. Before wasting more discussion over it I guess I'd like to know which backends don't support generalized clipping for lines and polygons. Perry
>>>>> "Perry" == Perry Greenfield <pe...@st...> writes: Perry> Is the essence of the issue here whether clipping is Perry> working properly, in particular, the backend clipping? I Perry> would have thought that backend clipping should handle this Perry> properly. For which backends does it not? If it doesn't Perry> for some, perhaps the issue is to supply our own software Perry> clipping; algorithm (possibly much slower though) as an Perry> option. Backend clipping works when the points are on the canvas (the canvas is the entire figure, not just the axes). Eg, on a 100x100 canvas, with a line from (0,0) to (100,100) you can clip to the (25,25) (75,75) rectangle. No problems there. In Srinath's case, we've asked the backend to plot, for example, a line from (0,-50000), (0,100) and then clip to the (25,25) (75,75) rectangle. I don't think the average backend (GTK, Agg) knows what to do with this line since they expect bitmap/display coords; there are no backend transformations - everything happens on the front end (clearly there are pros and cons of this approach, see below). With data clipping turned, the line class throws out the (0,-50000) point as illegal. To fix this in the current framework, we have to identify line segments in the x,y arrays which intersect the view port but with one or more end points outside the viewlim, and then draw the appropriate line through view port. This issue primarily arises for connected points (line styles '-', '--', and '-.' ). For symbol lines, data clipping already does the right thing, which is to throw the point away. However, there are hypothetical wacky cases you can imagine when you feel like being mean to matplotlib, like a 'o' circle marker 5 million miles from the view limits with a 5 million and one mile radius..... For connected lines, this could be very costly to implement since we have to loop over potentially very long arrays; for markers it would be worse. Refactoring transforms to the backend would probably fix this entirely. While non-trivial, this may be the best long term solution, especially when we want to do things like line and patch collections for efficient drawing of large numbers of objects. The two major benefits of the current transform architecture are 1) it lets you specify locations like 5 points to the left of the right y axes, and have the transform automatically update in the presence of window resizes, dpi changes, etc... Very nice when drawing ticks.... and 2) backends only have to think about one coord system, display, which makes it easier to implement a backend. I'm not convinced that it is a terrible thing to have a policy that matplotlib only plots line segments and markers whose vertices are in the axes limits, but I'm open to being convinced. JDH
John Hunter writes: > >>>>> "Srinath" == Srinath Avadhanula <sr...@fa...> writes: > > Srinath> Besides whether or not its a common enough situation is > Srinath> very application specific. I was planning to use > Srinath> matplotlib to display a complex layout. At the original > Srinath> scale, not much can be seen. There necessarily has to be > Srinath> a lot of scaling to see the details. > > Well, it's not complex scaling that causes troubles. The case where > you see this failure is when you are drawing a connected line between > two points where one or both of the points is far outside the view > limits. > Is the essence of the issue here whether clipping is working properly, in particular, the backend clipping? I would have thought that backend clipping should handle this properly. For which backends does it not? If it doesn't for some, perhaps the issue is to supply our own software clipping; algorithm (possibly much slower though) as an option. Perry
>>>>> "Srinath" == Srinath Avadhanula <sr...@fa...> writes: Srinath> Besides whether or not its a common enough situation is Srinath> very application specific. I was planning to use Srinath> matplotlib to display a complex layout. At the original Srinath> scale, not much can be seen. There necessarily has to be Srinath> a lot of scaling to see the details. Well, it's not complex scaling that causes troubles. The case where you see this failure is when you are drawing a connected line between two points where one or both of the points is far outside the view limits. Srinath> Could you let me know which files in matplotlib have the Srinath> code in question? I'll take a look then. The two relevant methods are matplotlib.transforms.Transform.positions and matplotlib.lines.Line2D._draw. I think the best place to start would be in the latter function. Let the transform do it's thing and then look for negative points. Note there are two kinds of clipping in matplotlib: data clipping and view clipping. data clipping removes data outside the view limits before transpose and plotting. view clipping is a renderer operation that prevents lines from being drawn outside the axes box. data clipping would remove a point from a connected line outside the viewport and prevent any part of that line from being drawn, even the part in the view port. view clipping would only clip the part that extends outside the viewport. The decision to use one or the other is often motivated by performance. Eg, if you want to plot a very large data set with only a small fraction in the viewport (which I often do), you often want to use data clipping to reduce the data set before transform and rendering. If you normally plot data with limits near the viewport limits you probably do not want the extra performance overhead and are happy with just view clipping which gives the "usual" result. That is why it's a configurable parameter. In earlier versions of matplotlib data clipping was on by default so data outside the view ports was removed. That is probably why we didn't see this negative transform error earlier. But experiments revealed that in the most common cases, data clipping did not provide an extra performance benefit, and occasionally surprised users in cases very similar to yours where one point of a connected line was outside the viewport and the entire line was removed. Given that negative display coords are essentially undefined (and backend dependent) at this point, I'm going to re-enable data clipping in the default matplotlibrc file, and I suggest most users do the same. There may be modulo operations on data points very far outside the data set that generate negative display values, or display values far larger than the display limits, each of which could cause artifact points. The ideal solution is yet to be found, but I'm open to suggestions and improvements. JDH
>>>>> "Peter" == Peter Juvan <pet...@fr...> writes: Peter> I prefer pcolor over imshow - I need to represent values Peter> from a 12x12 matrix as colors. Please modify pcolor Peter> arguments to use a custom colormap. Where / when will I be Peter> able to obtain the modified version? -Peter For 12x12 pcolor should work great. I included the pcolor cmap kwarg for the next release, which is starting to look like tomorrow rather than today ..... JDH
> From: John Hunter [mailto:jdh...@ac...] > > Note, if you really need the > functionality of pcolor over imshow (eg you want to set some > properties on the rectangle patches), I can modify the pcolor argument > list to use your custom colormap. I prefer pcolor over imshow - I need to represent values from a 12x12 matrix as colors. Please modify pcolor arguments to use a custom colormap. Where / when will I be able to obtain the modified version? -Peter
>>>>> "Peter" == Peter Juvan <pet...@fr...> writes: Peter> Q: Is it possible to change the default color scale of the Peter> matplotlib.matlab.pcolor plot? How? -Peter You can define your own colormap by subclassing matplotlib.colors.Colormap and then passing this to imshow in the cmap argument. Note that for the most part pcolor and imshow have the same functionality, but imshow is 1000 times faster for large grids. Compare pcolor_demo.py and pcolor_demo2.py in the examples dir which use pcolor and imshow respectively. Note, if you really need the functionality of pcolor over imshow (eg you want to set some properties on the rectangle patches), I can modify the pcolor argument list to use your custom colormap. If you define a new colormap (currently we have only jet and grayscale), please send it back to the list so I can include it. JDH
>>>>> "Jaanus" == Jaanus Karo <jaa...@ph...> writes: Jaanus> Can I create graphs with two different y-axes? Look for the 0.53 release later this afternoon. Download the src distribution and see examples/two_scales.py. JDH
>>>>> "Kenneth" == Kenneth McDonald <kmm...@wi...> writes: Kenneth> Couldn't see the answers to these questions when looking Kenneth> through the class reference docs, but they seem like Kenneth> common tasks, so I suspect there are standard idiomatic Kenneth> way of doing these. Could anyone refer me to examples Kenneth> showing Actually, neither of these exist in matplotlib-0.52, but see below. Kenneth> 1) How to most easily label the x axis for data which is Kenneth> plotted by date? (More specifically; does matplotlib have Kenneth> any understanding of date values, and if so, how do I Kenneth> access and use it?) I'm hoping there's an easier way than Kenneth> explicitly labelling ticks on the x axis. Full date support in matplotlib-0.53. Release should be this afternoon. The new examples will be examples/date_demo*.py. Kenneth> 2) I'll be drawing logy graphs, and I want a certain Kenneth> slope to indicate a certain rate of growth, which means Kenneth> that, when using matplotlib via TkAgg, I want it to keep Kenneth> the ratio of the graph display height and display width Kenneth> constant as it resizes the graph to take into account Kenneth> changes in the size of the enclosing window. Is there a Kenneth> standard way to do this? This is a good idea but it's not implemented and should be. How do you think the best way is to indicate a constrained resize? With a modifier key held down during the resize? JDH
Q: Is it possible to change the default color scale of the matplotlib.matlab.pcolor plot? How? -Peter
Hello! Can I create graphs with two different y-axes? Jaanus