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
(10) |
2
(3) |
3
(5) |
4
(7) |
5
(18) |
6
(4) |
7
(15) |
8
(7) |
9
(10) |
10
(4) |
11
(18) |
12
(15) |
13
(11) |
14
(11) |
15
(4) |
16
(28) |
17
(17) |
18
(22) |
19
(12) |
20
(19) |
21
(17) |
22
(14) |
23
(4) |
24
(3) |
25
(6) |
26
(8) |
27
(13) |
28
(11) |
29
(21) |
30
(3) |
31
(5) |
|
|
|
|
|
|
From: Eric E. <ems...@ob...> - 2006-12-29 07:39:49
|
ok thanks for the check. Since it seems like a personal setting pb, I have now restarted from a clean matplotlibrc and set up my prefered option. It now works (no clue why it didn't...) sorry for the trouble and thanks for doing that test. cheers Eric Eric Firing wrote: > It works on my machine (linux) with svn, but I don't see anything > about this in CHANGELOG. > > Eric > > Eric Emsellem wrote: >> hi, >> >> I am trying to have text written on 2 lines, but everything is written >> on a single line. Is that normal? >> >> here is an example: >> >> plot(arange(10)) >> ylabel('this is vertical \n test') >> text(0.5,0.5,"this is a test \n but does not work") >> >> thanks >> Eric >> ======================= >> Suse 10.1 >> matplotlib version 0.87.7 >> numerix numpy 1.0.2.dev3491 >> Python 2.4.2 (#1, May 2 2006, 08:13:46) >> IPython 0.7.4.svn.r2010 -- An enhanced Interactive Python. >> >> |
From: John H. <jdh...@ac...> - 2006-12-29 05:52:55
|
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> either, indistinguishably from the way it does now. The Eric> problem is that with a linear axis we want the axis to start Eric> at zero by default, but with a log axis we want it to start With ymin at 1e-100, the default (linear) locator should choose 0 as ymin. If it doesn't it looks like a bug. Is either the log or linear autoscaler broken for bottom=something-really-small ? JDH |
From: Eric F. <ef...@ha...> - 2006-12-29 05:40:49
|
Diwaker Gupta wrote: >> Examples: >> >> This makes a sensible plot that behaves well under zooming and panning: >> hist(randn(1000), log=True) >> show() > > Thanks! However... > >> The following still generates an exception: >> hist(randn(1000)) >> gca().set_yscale('log') >> show() > > I think this makes the API more confusing. As an end user, I want the > API to be consistent and intuitive. Its weird if I can set log scale > after all plot commands, but not after calling hist. And yet, log > scale DOES work with that keyword arg. I might even think things were > broken had I not been following this thread. > > Anyways, thanks for looking into this! I agree that it is not optimal, but I have not figured out any simple way of making bar (which is the underlying plot command) do the right thing without knowing beforehand whether it is dealing with a log or a linear axis. It simply has to make different choices for the patch (rectangle) corners and the data limits that are used for autoscaling. For this to work correctly in an interactive mode with set_yscale('log') called after the hist or bar command would require a mechanism for undoing and then redoing the hist or bar command. Such a mechanism could be developed, but it would require some structural changes in mpl (or maybe some very ugly hacks), and I don't see that this particular problem is bad enough to motivate such changes. Actually, I think the sticking point is the autoscaling, not the patches. For the default "bottom=None" case, we could set bottom to 1e-100 for both the log and linear axes, and for all practical purposes it would work correctly for either, indistinguishably from the way it does now. The problem is that with a linear axis we want the axis to start at zero by default, but with a log axis we want it to start a bit below the lowest bar, so the autoscaling is inherently different and needs to be based on a different dataLim bounding box. Maybe in time we will figure out better solutions. Eric |
From: Diwaker G. <diw...@gm...> - 2006-12-29 02:25:23
|
> Examples: > > This makes a sensible plot that behaves well under zooming and panning: > hist(randn(1000), log=True) > show() Thanks! However... > The following still generates an exception: > hist(randn(1000)) > gca().set_yscale('log') > show() I think this makes the API more confusing. As an end user, I want the API to be consistent and intuitive. Its weird if I can set log scale after all plot commands, but not after calling hist. And yet, log scale DOES work with that keyword arg. I might even think things were broken had I not been following this thread. Anyways, thanks for looking into this! -- Web/Blog/Gallery: http://floatingsun.net/blog |
From: Eric F. <ef...@ha...> - 2006-12-28 23:36:56
|
It works on my machine (linux) with svn, but I don't see anything about this in CHANGELOG. Eric Eric Emsellem wrote: > hi, > > I am trying to have text written on 2 lines, but everything is written > on a single line. Is that normal? > > here is an example: > > plot(arange(10)) > ylabel('this is vertical \n test') > text(0.5,0.5,"this is a test \n but does not work") > > thanks > Eric > ======================= > Suse 10.1 > matplotlib version 0.87.7 > numerix numpy 1.0.2.dev3491 > Python 2.4.2 (#1, May 2 2006, 08:13:46) > IPython 0.7.4.svn.r2010 -- An enhanced Interactive Python. > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
From: Eric E. <ems...@ob...> - 2006-12-28 23:11:42
|
hi, I am trying to have text written on 2 lines, but everything is written on a single line. Is that normal? here is an example: plot(arange(10)) ylabel('this is vertical \n test') text(0.5,0.5,"this is a test \n but does not work") thanks Eric ======================= Suse 10.1 matplotlib version 0.87.7 numerix numpy 1.0.2.dev3491 Python 2.4.2 (#1, May 2 2006, 08:13:46) IPython 0.7.4.svn.r2010 -- An enhanced Interactive Python. |
From: Eric F. <ef...@ha...> - 2006-12-28 21:40:08
|
John, Thank you for your thorough and thoughtful reply. OK, I am convinced. I had not realized that the present line-drawing code actually is omitting nonpositive points, but now I see the Line.get_plottable() method. I have committed changes to svn that I think will be helpful--maybe good enough for now. From the CHANGELOG: 2006-12-28 Improved error message for nonpositive input to log transform; added log kwarg to bar, barh, and hist, and modified bar method to behave sensibly by default when the ordinate has a log scale. (This only works if the log scale is set before or by the call to bar, hence the utility of the log kwarg.) - EF Examples: This makes a sensible plot that behaves well under zooming and panning: hist(randn(1000), log=True) show() The following still generates an exception: hist(randn(1000)) gca().set_yscale('log') show() but the traceback is more informative and ends with: /usr/local/lib/python2.4/site-packages/matplotlib/patches.py in draw(self, renderer) 183 184 verts = self.get_verts() --> 185 tverts = self.get_transform().seq_xy_tups(verts) 186 187 renderer.draw_polygon(gc, rgbFace, tverts) ValueError: Cannot take log of nonpositive value I have not put in any form of your suggested addition to set_yscale and set_xscale. Maybe I should, but I am hoping that the changes above are sufficient. Eric John Hunter wrote: >>>>>> "Eric" == Eric Firing <ef...@ha...> writes: > > Eric> Adjusting zero and negative values (or maybe just zero) > Eric> would be unacceptable in a numerics library, but in the > Eric> context of our graphical transforms it is analogous to > Eric> clipping, and this we do all the time--we don't raise an > Eric> exception if someone tries to plot outside the box. (This > Eric> clipping strategy to handle nonpositive values is present > Eric> already in the LogLocator.) > > I'm more comfortable dropping points than I am altering the data. > Consider some use case like > > ax.hist(...) > rect = Rectangle(...) > ax.add_patch(rect) > ax.set_xscale('log') > > In set_xscale we only see a bunch of rectangles. User defined > rectangles may be used to store data (eg the JPL uses custom bars with > xlimits that are the start and stop times when orbiting spacecraft are > within view of a ground station). Some of these users will also want > to "pick" the rectangle and inspect the data values. If we are > altering them, they have no guarantee that what they put in is what > they get out. Now we might argue that they get what they deserve if > they are using invalid data for a log scale, but one good solution in > my view is to fail noisily with helpful messages, and provide an easy > interface to do it right. > > But if I am missing your point or you have an implementation that will > address these concerns, I'm certainly open to them. One possibility > is to flag artists that we create internally (eg hist) and take more > liberty with these, or have some flag like the Artist "clip_on" > property which allows the user to control whether their data is > mutable to support "helpful" alterations for log or other > transformations. > > Eric> We can use such a small adjustment value that a problem such > Eric> as you mention above is highly unlikely--and note that > Eric> floating point itself has limitations, and does not permit > Eric> arbitrarily small or large numbers. Furthermore, note that > > Eric> the user can always take advantage of the bottom kwarg. And > Eric> if in some extreme case the user has not used the bottom > Eric> kwarg and the bars really are shorter than the adjustment > Eric> value, it will probably be quite obvious. > > The other thing to think about is choosing a bottom so that the > natural range of the tops is revealed. Eg if the bottom is 1e-200, > all the bars will appear the same height in many cases. > > Eric> It is in ordinary line plotting that adjusting the value > Eric> could be misleading--it plots an extremely small number (if > Eric> the data limits are set to include it) instead of zero. > Eric> Maybe this is enough of a drawback to nix the whole idea. > > I am happy with the current behavior of culling the non-positive > points. matlab does it and noone has complained here. There is a > difference in lines created with "plot" and bars created with hist: in > the former case the users explicitly picked the x,y points. In the > latter they implicitly do so with a default bottom kwarg that they may > have overlooked. This suggests to me that we need not treat the two > cases the same. > > Eric> Every alternative that you propose is more complicated and > Eric> less comprehensive than the low-level adjustment, however, > Eric> and I see little if any real advantage to the alternatives. > > If you would like to take a stab at an implementation I am happy to be > persuaded (with caveats below). In the simple case of > > ax.hist() > ax.set_xscale('log') > > this would indeed be fairly easy because you know how the data were > created. In the general case where the user has added lots-o-patches > to the axes, it may not be easy to do well. I'm still inclined to the > "explicit is better than implicit" and either require them to do one of > > 1) use the bottom kwarg > > 2) set log scaling before calling hist -- we can make the default > bottom=None and do different things for linear and log scaling > > 3) use a loghist function > > Eric> If you still don't want the adjustment, then the easiest way > Eric> to improve the error message would be to raise a Python > Eric> exception instead of a c++ error in places like > > Eric> for(int i=0; i < length; i++) { if (x<=0) { throw > Eric> std::domain_error("Cannot take log of nonpositive value"); } > Eric> else newx[i] = log10(x[i]); > Eric> } > > Eric> The domain error message above is informative, but it never > Eric> makes it out to the user. > > I really don't feel too strongly about this -- my gut reaction is that > a helpful message and an easy way to fix it is enough and it won't get > us into a possible quagmire of trying to be too smart. Personally, I > don't like it when computers try to be too helpful (think MS windows > and clippy); I like it when they do what I tell them to do. With the > snippet I posted previously we can easily warn them before doing the > transformation and with bottom=None we can handle the case when the > log scale is set before the call to hist. That in conjunction with > some additional docstrings in hist should work reasonably well. > > That said, if you want to try something more ambitious I won't get in > your way. I recommend at a minimum that you have some artist flag > that governs whether mpl can make helpful data alterations (just as we > do with clip) so the power user can turn it off. > > JDH |
From: Jeff W. <js...@fa...> - 2006-12-28 21:22:20
|
Chris Pettit wrote: > Thanks in advance to anyone who can help. This is my first extended > attempt to make matplotlib work, and I'm relatively new to the whole > Python world. I have MacPython2.4 running now, which seems to work > fine. I installed everything for matplotlib, scipy, etc., from the > Mac OS 10.4 SciPy Superpack binaries, so I didn't expect to have much > trouble, but I get the following when I try to import pylab: > > >>> from pylab import * > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/pylab.py", line 1, in ? > from matplotlib.pylab import * > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/matplotlib/pylab.py", line 202, in ? > from axes import Axes, PolarAxes > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/matplotlib/axes.py", line 15, in ? > from axis import XAxis, YAxis > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/matplotlib/axis.py", line 25, in ? > from font_manager import FontProperties > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/matplotlib/font_manager.py", line 39, in ? > from matplotlib import ft2font > ImportError: Failure linking new module: /Library/Frameworks/ > Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/ > ft2font.so: Symbol not found: _FMDisposeFontFamilyIterator > Referenced from: /usr/local/lib/libfreetype.6.dylib > Expected in: flat namespace > > > I saw a couple of posts about problems caused by libfreetype in the > most recent Apple X11 update, so I tried reinstalling Freetype2 from > souce and ended up with libfreetype6.3.10 in my /usr/local/lib. I > tried moving this to my /usr/X11R6/lib and resetting the symbolic > links to point to this, but no luck. > > Any advice? > > Thanks, > Chris Pettit > > Chris: Do you have /usr/local/lib/libfreetype.6.dylib? (it should be a symlink to /usr/local/lib/libfreetype.6.3.dylib) If you do, I imagine that your version of libfreetype is old and doesn't have the _FMDisposeFontFamilyIterator symbol. You could try setting the /usr/local/lib/libfreetype.6.dylib symlink to point to /usr/X11R6/lib/libfreetype.6.3.x.dylib. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: Chris P. <pet...@ma...> - 2006-12-28 21:13:38
|
Thanks in advance to anyone who can help. This is my first extended attempt to make matplotlib work, and I'm relatively new to the whole Python world. I have MacPython2.4 running now, which seems to work fine. I installed everything for matplotlib, scipy, etc., from the Mac OS 10.4 SciPy Superpack binaries, so I didn't expect to have much trouble, but I get the following when I try to import pylab: >>> from pylab import * Traceback (most recent call last): File "<stdin>", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/pylab.py", line 1, in ? from matplotlib.pylab import * File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/matplotlib/pylab.py", line 202, in ? from axes import Axes, PolarAxes File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/matplotlib/axes.py", line 15, in ? from axis import XAxis, YAxis File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/matplotlib/axis.py", line 25, in ? from font_manager import FontProperties File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/matplotlib/font_manager.py", line 39, in ? from matplotlib import ft2font ImportError: Failure linking new module: /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/ ft2font.so: Symbol not found: _FMDisposeFontFamilyIterator Referenced from: /usr/local/lib/libfreetype.6.dylib Expected in: flat namespace I saw a couple of posts about problems caused by libfreetype in the most recent Apple X11 update, so I tried reinstalling Freetype2 from souce and ended up with libfreetype6.3.10 in my /usr/local/lib. I tried moving this to my /usr/X11R6/lib and resetting the symbolic links to point to this, but no luck. Any advice? Thanks, Chris Pettit |
From: Jeff W. <js...@fa...> - 2006-12-28 20:32:16
|
Petr Danecek wrote: > Hello, > first of all: thanks for the great software!! After the years of > struggling with gnuplot, i really enjoy making my graphs with > matplotlib. > > I'd like to ask, if it is possible to create a contour graph using polar > coordinates? If not, can someone give me some pointers about how to > implement it? > > Kind regards, > Petr Danecek > > > Here's a slightly prettier version of my previous example: from pylab import * deltatheta = 2.*pi/100. theta = arange(0.,2.*pi+0.5*deltatheta,deltatheta) R = arange(0.,pi,deltatheta) r,t = meshgrid(R, theta) Z = sin(r)*sin(3.*t) X = r*cos(t) Y = r*sin(t) ax = subplot(111) cs = ax.contourf(X,Y,Z) # make sure aspect ratio preserved ax.set_aspect('equal') # turn off rectangular frame. ax.set_frame_on(False) # turn off axis ticks. ax.set_xticks([]) ax.set_yticks([]) # draw a circle around the edge of the plot. rmax = max(R) ax.plot(rmax*cos(theta),rmax*sin(theta),'k') title('Polar contours') show() -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: Jeff W. <js...@fa...> - 2006-12-28 20:10:59
|
Petr Danecek wrote: > Hello, > first of all: thanks for the great software!! After the years of > struggling with gnuplot, i really enjoy making my graphs with > matplotlib. > > I'd like to ask, if it is possible to create a contour graph using polar > coordinates? If not, can someone give me some pointers about how to > implement it? > > Kind regards, > Petr Danecek > > Petr: I don't think contour directly supports polar axes, but if your data are in polar coordinates you can easily make a contour plot with cartesian axes, like this: from pylab import * deltatheta = 2.*pi/100. theta = arange(0.,2.*pi,deltatheta) R = arange(0.,pi,deltatheta) r,t = meshgrid(R, theta) Z = sin(r)*sin(3.*t) X = r*cos(t) Y = r*sin(t) cs = contourf(X,Y,Z) show() -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: Petr D. <da...@uc...> - 2006-12-28 19:25:00
|
Hello, first of all: thanks for the great software!! After the years of struggling with gnuplot, i really enjoy making my graphs with matplotlib. I'd like to ask, if it is possible to create a contour graph using polar coordinates? If not, can someone give me some pointers about how to implement it? Kind regards, Petr Danecek |
From: John H. <jdh...@ac...> - 2006-12-28 14:56:06
|
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> Adjusting zero and negative values (or maybe just zero) Eric> would be unacceptable in a numerics library, but in the Eric> context of our graphical transforms it is analogous to Eric> clipping, and this we do all the time--we don't raise an Eric> exception if someone tries to plot outside the box. (This Eric> clipping strategy to handle nonpositive values is present Eric> already in the LogLocator.) I'm more comfortable dropping points than I am altering the data. Consider some use case like ax.hist(...) rect = Rectangle(...) ax.add_patch(rect) ax.set_xscale('log') In set_xscale we only see a bunch of rectangles. User defined rectangles may be used to store data (eg the JPL uses custom bars with xlimits that are the start and stop times when orbiting spacecraft are within view of a ground station). Some of these users will also want to "pick" the rectangle and inspect the data values. If we are altering them, they have no guarantee that what they put in is what they get out. Now we might argue that they get what they deserve if they are using invalid data for a log scale, but one good solution in my view is to fail noisily with helpful messages, and provide an easy interface to do it right. But if I am missing your point or you have an implementation that will address these concerns, I'm certainly open to them. One possibility is to flag artists that we create internally (eg hist) and take more liberty with these, or have some flag like the Artist "clip_on" property which allows the user to control whether their data is mutable to support "helpful" alterations for log or other transformations. Eric> We can use such a small adjustment value that a problem such Eric> as you mention above is highly unlikely--and note that Eric> floating point itself has limitations, and does not permit Eric> arbitrarily small or large numbers. Furthermore, note that Eric> the user can always take advantage of the bottom kwarg. And Eric> if in some extreme case the user has not used the bottom Eric> kwarg and the bars really are shorter than the adjustment Eric> value, it will probably be quite obvious. The other thing to think about is choosing a bottom so that the natural range of the tops is revealed. Eg if the bottom is 1e-200, all the bars will appear the same height in many cases. Eric> It is in ordinary line plotting that adjusting the value Eric> could be misleading--it plots an extremely small number (if Eric> the data limits are set to include it) instead of zero. Eric> Maybe this is enough of a drawback to nix the whole idea. I am happy with the current behavior of culling the non-positive points. matlab does it and noone has complained here. There is a difference in lines created with "plot" and bars created with hist: in the former case the users explicitly picked the x,y points. In the latter they implicitly do so with a default bottom kwarg that they may have overlooked. This suggests to me that we need not treat the two cases the same. Eric> Every alternative that you propose is more complicated and Eric> less comprehensive than the low-level adjustment, however, Eric> and I see little if any real advantage to the alternatives. If you would like to take a stab at an implementation I am happy to be persuaded (with caveats below). In the simple case of ax.hist() ax.set_xscale('log') this would indeed be fairly easy because you know how the data were created. In the general case where the user has added lots-o-patches to the axes, it may not be easy to do well. I'm still inclined to the "explicit is better than implicit" and either require them to do one of 1) use the bottom kwarg 2) set log scaling before calling hist -- we can make the default bottom=None and do different things for linear and log scaling 3) use a loghist function Eric> If you still don't want the adjustment, then the easiest way Eric> to improve the error message would be to raise a Python Eric> exception instead of a c++ error in places like Eric> for(int i=0; i < length; i++) { if (x<=0) { throw Eric> std::domain_error("Cannot take log of nonpositive value"); } Eric> else newx[i] = log10(x[i]); Eric> } Eric> The domain error message above is informative, but it never Eric> makes it out to the user. I really don't feel too strongly about this -- my gut reaction is that a helpful message and an easy way to fix it is enough and it won't get us into a possible quagmire of trying to be too smart. Personally, I don't like it when computers try to be too helpful (think MS windows and clippy); I like it when they do what I tell them to do. With the snippet I posted previously we can easily warn them before doing the transformation and with bottom=None we can handle the case when the log scale is set before the call to hist. That in conjunction with some additional docstrings in hist should work reasonably well. That said, if you want to try something more ambitious I won't get in your way. I recommend at a minimum that you have some artist flag that governs whether mpl can make helpful data alterations (just as we do with clip) so the power user can turn it off. JDH |
From: Achim G. <Ach...@ph...> - 2006-12-28 11:36:50
|
Hi Steve! Yes, that's right. Most of the people will help themselves with saving the picture and then printing by an arbitary program. On Linux I would implement printing via pipelines to lp, but on Windows I have no clue how to get the job done. So I was glad to find the PrintOperations for GTK2 (>=2.10), which were portable to different OS supported by GTK. For a print button in matplotlib it is necessary to find implementations for other widget sets: * tk * wx * qt I expect, that there is enough support for printing in qt, but I do not know anything about tk or wx. My code is just a starter for this process... or at least a try. Yours, Achim Steve Chaplin wrote: > If I understand correctly you are suggesting that a new icon, "print the > figure" be added to the matplotlib toolbar, to function in a similar way > to the "File / Print .." menu on many other applications. > I don't do any printing myself so it does not affect me, but it looks > like a reasonable request. However, I didn't see any replies to your > mail so are there really many matplotlib people missing this button? > |
From: Eric F. <ef...@ha...> - 2006-12-28 02:00:00
|
John Hunter wrote: >>>>>> "Eric" == Eric Firing <ef...@ha...> writes: > > Eric> Oops, I replied to your previous message before seeing this > Eric> one. Still, the larger question remains: maybe we should do > Eric> something to make it easier for users to understand what is > Eric> going on when the transform chokes on log(0). Changing > Eric> numbers <=0 to a small positive number and issuing a warning > Eric> would accomplish this, and I don't see much disadvantage. > > This is tricky to implement in practice. Eg, what if the user did a > bar graph where the heights were order 1e-10? Without knowing what > the user intended when creating the graphics primitives it is > difficult to know what to do with them. I am hesitant to alter data > at the level of graphics primitives without knowing the operation that > created them. One possible solution may be to simply create a John, Adjusting zero and negative values (or maybe just zero) would be unacceptable in a numerics library, but in the context of our graphical transforms it is analogous to clipping, and this we do all the time--we don't raise an exception if someone tries to plot outside the box. (This clipping strategy to handle nonpositive values is present already in the LogLocator.) We can use such a small adjustment value that a problem such as you mention above is highly unlikely--and note that floating point itself has limitations, and does not permit arbitrarily small or large numbers. Furthermore, note that the user can always take advantage of the bottom kwarg. And if in some extreme case the user has not used the bottom kwarg and the bars really are shorter than the adjustment value, it will probably be quite obvious. It is in ordinary line plotting that adjusting the value could be misleading--it plots an extremely small number (if the data limits are set to include it) instead of zero. Maybe this is enough of a drawback to nix the whole idea. Every alternative that you propose is more complicated and less comprehensive than the low-level adjustment, however, and I see little if any real advantage to the alternatives. > helper function (loghist, logbar) which works like semilogx: it knows > what the user wants to do and does the right thing, in this case > making sure that the "bottom" of the rectangles is some suitable > positive number less than all the heights. > > I definitely agree that the error message is not terribly helpful. If you still don't want the adjustment, then the easiest way to improve the error message would be to raise a Python exception instead of a c++ error in places like for(int i=0; i < length; i++) { if (x<=0) { throw std::domain_error("Cannot take log of nonpositive value"); } else newx[i] = log10(x[i]); } The domain error message above is informative, but it never makes it out to the user. It looks like one variation on my suggestion--warning when adjusting a nonpositive value--would be difficult to implement. Eric > One possibility is to inspect most of the objects at set_xscale and > set_yscale and issue a warning if there is non-positive data. > > Eg: 'one or more patches has a non-positive y coordinate' > > This won't be too helpful for mpl newbies who don't know what a patch > is, but it will provide some additional information (at the expense of > inspecting all the data at scale changes) > > Something like > > if xscale=='log': > for line in self.lines: > xdata = line.get_xdata(valid_only = True) > if min(xdata)<=0.: > warn on lines and break > > for patch in self.patches: > if min([x for x,y in patch.get_verts()])<=0.: > warn on patches and break > > for collection in self.collections: > if min([x for x,y in collection.get_verts()])<=0.: > warn on collections and break > > > JDH |
From: John H. <jdh...@ac...> - 2006-12-27 20:18:40
|
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> Oops, I replied to your previous message before seeing this Eric> one. Still, the larger question remains: maybe we should do Eric> something to make it easier for users to understand what is Eric> going on when the transform chokes on log(0). Changing Eric> numbers <=0 to a small positive number and issuing a warning Eric> would accomplish this, and I don't see much disadvantage. This is tricky to implement in practice. Eg, what if the user did a bar graph where the heights were order 1e-10? Without knowing what the user intended when creating the graphics primitives it is difficult to know what to do with them. I am hesitant to alter data at the level of graphics primitives without knowing the operation that created them. One possible solution may be to simply create a helper function (loghist, logbar) which works like semilogx: it knows what the user wants to do and does the right thing, in this case making sure that the "bottom" of the rectangles is some suitable positive number less than all the heights. I definitely agree that the error message is not terribly helpful. One possibility is to inspect most of the objects at set_xscale and set_yscale and issue a warning if there is non-positive data. Eg: 'one or more patches has a non-positive y coordinate' This won't be too helpful for mpl newbies who don't know what a patch is, but it will provide some additional information (at the expense of inspecting all the data at scale changes) Something like if xscale=='log': for line in self.lines: xdata = line.get_xdata(valid_only = True) if min(xdata)<=0.: warn on lines and break for patch in self.patches: if min([x for x,y in patch.get_verts()])<=0.: warn on patches and break for collection in self.collections: if min([x for x,y in collection.get_verts()])<=0.: warn on collections and break JDH |
From: maser r. <mas...@ya...> - 2006-12-27 20:03:19
|
Hi Guys, I'm a new user of Matplotlib and am very impressed by its plotting capabilities. I have the latest version of Matplotlib and Numpy 1.0 running on my Win 2000 system with Python 2.4. On running the pythonic_matplotlib.py,cursor_demo.py etc.. in Matplotlib examples in the Pythonwin interpreter, the program runs fine, the tk window shows up and when I close the window by way of the 'x' on the right hand side, it closes fine. But however, when I reload pythonic_matplotlib.py, and run it again (by pressing F5), the tk window shows up, but the all the functions on the toolbar do not work. When I press the 'x' on the right hand side of the window, it shows the following message and Pythonwin crashes. "Runtime Error! Program: c:\Python24\Lib\site-packages\pythonwin\pythonwin.exe This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information" I was wondering what the issue could be. Your response is greatly appreciated. Thanks. Maser --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. |
From: Simson G. <si...@ac...> - 2006-12-27 19:12:28
|
On Dec 16, 2006, at 1:58 PM, Pierre GM wrote: >> I've also written a neat pre-processor that allows you to embed >> python and matplotlib code in LaTeX, so you don't need to have it all >> spread out. And you can populate the results from SQL queries, right >> there in the LaTeX. It makes paper writing much easier. > Oh, that sounds great ! Could you post it somewhere ? I'm sure it'd > be quite > useful (I do have a need for it myself...) I've made an initial release at http://www.simson.net/pylatex.tar.gz It's very preliminary, and you'll need to figure out the latex stuff yourself. I had wanted to put in some more examples, but haven't figure out a good way to do it easily.... |
From: Eric F. <ef...@ha...> - 2006-12-27 18:58:30
|
Oops, I replied to your previous message before seeing this one. Still, the larger question remains: maybe we should do something to make it easier for users to understand what is going on when the transform chokes on log(0). Changing numbers <=0 to a small positive number and issuing a warning would accomplish this, and I don't see much disadvantage. Eric John Hunter wrote: >>>>>> "John" == John Hunter <jdh...@ac...> writes: > > John> You have to make sure your yaxis limits are strictly > John> positive, eg > > John> ax.set_ylim(1e-3, 1e3) ax.set_yscale('log') > > No that won't quite do it, sorry for the noise. The problem is that > the histogram bottom of the rectangle is zero by default, and > transforming those vertices are causing the problem. You need to use > the "bottom" kwarg to set the bottom of the bars to be positive, eg > > hist(rand(100), 20, bottom=1e-3) > > JDH > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
From: Eric F. <ef...@ha...> - 2006-12-27 18:52:08
|
John Hunter wrote: >>>>>> "Diwaker" == Diwaker Gupta <diw...@gm...> writes: > > >> >> The following minimal script reveals a rendering problem > >> with >> displaying a histogram on a log vertical axis. > > Diwaker> Has this been resolved yet? I'm running Matplotlib > Diwaker> 0.87.5-2.2 on Debian Unstable. I try to run the following > Diwaker> script: > > Diwaker> from pylab import * hist(rand(100), 20) ax = gca() > Diwaker> ax.set_yscale('log') show() > > You have to make sure your yaxis limits are strictly positive, eg > > ax.set_ylim(1e-3, 1e3) > ax.set_yscale('log') This doesn't work. The problem is that the patch objects are made first, and they start at y=0, so changing the y limits doesn't prevent the attempt to take the log of zero. One solution would be to have the transform simply trap zero and negative inputs and change them, with or without a warning, to some very small positive value. This would do the right thing in the present case. In cases where a zero is used inadvertently and incorrectly, and where an exception really should be raised, it would not do so. Maybe this is a worthwhile tradeoff? This question has come up quite a few times, and it would be nice to stop that. A solution for hist would be a kwarg to handle the log case. If hist is the only context in which this problem arises--that is, if all other cases are ones in which the zero has no business being there so an exception is appropriate--then adding log-handling to hist would be the way to go. But I suspect there are other cases, and we will keep getting this question. It's understandable, because the exception that gets triggered is not very informative. Eric > > > JDH |
From: John H. <jdh...@ac...> - 2006-12-27 15:21:41
|
>>>>> "John" == John Hunter <jdh...@ac...> writes: John> You have to make sure your yaxis limits are strictly John> positive, eg John> ax.set_ylim(1e-3, 1e3) ax.set_yscale('log') No that won't quite do it, sorry for the noise. The problem is that the histogram bottom of the rectangle is zero by default, and transforming those vertices are causing the problem. You need to use the "bottom" kwarg to set the bottom of the bars to be positive, eg hist(rand(100), 20, bottom=1e-3) JDH |
From: John H. <jdh...@ac...> - 2006-12-27 14:29:58
|
>>>>> "Diwaker" == Diwaker Gupta <diw...@gm...> writes: >> >> The following minimal script reveals a rendering problem >> with >> displaying a histogram on a log vertical axis. Diwaker> Has this been resolved yet? I'm running Matplotlib Diwaker> 0.87.5-2.2 on Debian Unstable. I try to run the following Diwaker> script: Diwaker> from pylab import * hist(rand(100), 20) ax = gca() Diwaker> ax.set_yscale('log') show() You have to make sure your yaxis limits are strictly positive, eg ax.set_ylim(1e-3, 1e3) ax.set_yscale('log') JDH |
From: Edin S. <edi...@gm...> - 2006-12-27 07:38:34
|
On 12/26/06, John Hunter <jdh...@ac...> wrote: > Did you rm -rf your build dir (and sometimes site-packages/matplotlib) > before rebuilding. This is usually the cause of such crashes. Yes I have. I even reinstalled windows (not related to matplotlib :), and I had the same problems. I'll experiment a bit more, but maybe the problem is not my system... ;) Cheers, Edin |
From: Eric F. <ef...@ha...> - 2006-12-27 06:23:55
|
The problem is still present in svn. Thanks for the reminder. Eric Diwaker Gupta wrote: >>>> The following minimal script reveals a rendering problem with >>>> displaying a histogram on a log vertical axis. > > Has this been resolved yet? I'm running Matplotlib 0.87.5-2.2 on > Debian Unstable. I try to run the following script: > > from pylab import * > hist(rand(100), 20) > ax = gca() > ax.set_yscale('log') > show() > > And get the error: > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", > line 284, in expose_event > self._render_figure(self._pixmap, w, h) > File "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py", > line 73, in _render_figure > FigureCanvasAgg.draw(self) > File "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", > line 391, in draw > self.figure.draw(renderer) > File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line > 538, in draw > for a in self.axes: a.draw(renderer) > File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1057, in draw > a.draw(renderer) > File "/usr/lib/python2.4/site-packages/matplotlib/patches.py", line > 165, in draw > tverts = self._transform.seq_xy_tups(verts) > ValueError: Domain error on nonlinear Transformation::seq_xy_tups > operator()(thisx, thisy) > > The error is always reproducible, both from the console and the ipython console. > > Any ideas? > > On 7/22/06, Gary Ruben <gr...@bi...> wrote: >> More information on this bug: on my WinXP laptop, it seems to only >> manifest under some circumstances. When running the script from inside >> SciTE or ipython, it seems more or less repeatable (sometimes it won't >> show on the first run but does from then on), but if the .py file is run >> directly from the windows explorer, it doesn't show up. On my win98 >> desktop, however, it shows up regardless. >> >> Gary Ruben wrote: >>> Note: I just verified that this was introduced into 0.87.4. >>> 0.87.3 doesn't exhibit the problem. See attachment. >>> >>> Gary R. >>> >>> gr...@bi... wrote: >>>> The following minimal script reveals a rendering problem with >>>> displaying a histogram on a log vertical axis. >>>> I'm using matplotlib0.87.4 in WinXP with python 2.3.5 Enthon. >>>> >>>> from pylab import * >>>> hist(rand(100), 20, bottom=1) >>>> setp(gca(), yscale="log") >>>> show() >>>> >>>> >>>> Gary R. > |
From: Alan G I. <ai...@am...> - 2006-12-27 05:26:23
|
On Tue, 26 Dec 2006, Eric Firing apparently wrote: > 1) edgecolor=facecolor is not the same as not drawing the > edge; it leads to artifacts that can be very damaging. Strongly agree! Cheers, Alan Isaac |