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
(14) |
2
(11) |
3
(5) |
4
(17) |
5
(11) |
6
(37) |
7
(35) |
8
(9) |
9
(1) |
10
(9) |
11
(7) |
12
(22) |
13
(34) |
14
(24) |
15
(27) |
16
(13) |
17
(19) |
18
(43) |
19
(36) |
20
(12) |
21
(9) |
22
(21) |
23
(3) |
24
(5) |
25
(30) |
26
(14) |
27
(23) |
28
(19) |
29
(19) |
30
(10) |
31
(6) |
|
|
|
|
|
|
> >> >> However, everyone would be happy if the default format would be >> consistent : >> >> As it is, *by default*, when <1000 it displays an int and after 1000 >> it displays 1.42e3. >> Why? What do you think this scientific format is a good for? >> >> I understand some users would like to see floats by default. >> Some other users would like to see integers by default. > > It is not just a matter of integer versus float; the formatting > algorithm must accomodate both. > I agree. >> >> I'm fine with integers or floats by default (I don't cadre) but I >> don't get the logic of the scientific format. >> I only would like to see all the digits of the integer parts. >> I would be fine if I would get 1.422e3 instead of 1.42e3 (we could >> for instance assume that images larger than (100 000, 100 000) are >> really a corner case ;)). >> >> Why should be the *default* logic so strange? >> Ok, it is easy to change but the default should at least make sense. >> As it is, I don't think it does...but there could be a good rational >> I'm missing. > > > Right now, the default is very simple: > > def format_data_short(self,value): > 'return a short formatted string representation of a number' > return '%1.3g'%value > > It looks like changing it to something like "%-12g" would facilitate > considerable improvement in reducing the jumping around of the > numbers, as well as in providing much more precision. I think that 12 > is the max number of characters in g conversion. Or maybe it is 13; I > might not have tested negative numbers. > > The problem is that then it crowds out the other part of the message, > the pan/zoom status notification etc. > > Breaking the message into two lines almost works (so far only checking > with gtkagg), but the plot gets resized depending on whether there is > a status or not. > > I think that with some more fiddling around with that part of the > toolbar--probably including breaking the message up into separate > messages for status and readout, and maybe making the readout use two > lines and always be present--we could make the readout and status > display much nicer. I have never liked the way it jumps around. > I also agree. However, I would like to be sure I understand one point correctly: As long as x<1000, the default format *is* an integer (at least when imshow(M) is used). Fine for me. Why do we need to move to another *default* format for numbers larger than 1000? Anyhow, I think that we should at least always display all the digits of the integer part of the coordinates. BTW, ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d')) is fine but it prevents you to do a simple imshow(M) to look at your data. You have to create ax. Easy...yes...but not as simple/nice as the one-liner imhow(M) Xavier > Eric > >> >> pylab is so easy and fun to use because the default settings are >> always the best one. >> IMHO, there is one exception :( >> >> Xavier >> >> >> >> ------------------------------------------------------------------------------ >> >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >> is a gathering of tech-side developers & brand creativity >> professionals. Meet >> the minds behind Google Creative Lab, Visual Complexity, Processing, >> & iPhoneDevCamp as they present alongside digital heavyweights like >> Barbarian Group, R/GA, & Big Spaceship. >> http://p.sf.net/sfu/creativitycat-com >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >
Xavier Gnata wrote: > > However, everyone would be happy if the default format would be consistent : > > As it is, *by default*, when <1000 it displays an int and after 1000 it > displays 1.42e3. > Why? What do you think this scientific format is a good for? > > I understand some users would like to see floats by default. > Some other users would like to see integers by default. It is not just a matter of integer versus float; the formatting algorithm must accomodate both. > > I'm fine with integers or floats by default (I don't cadre) but I don't > get the logic of the scientific format. > I only would like to see all the digits of the integer parts. > I would be fine if I would get 1.422e3 instead of 1.42e3 (we could for > instance assume that images larger than (100 000, 100 000) are really a > corner case ;)). > > Why should be the *default* logic so strange? > Ok, it is easy to change but the default should at least make sense. > As it is, I don't think it does...but there could be a good rational I'm > missing. Right now, the default is very simple: def format_data_short(self,value): 'return a short formatted string representation of a number' return '%1.3g'%value It looks like changing it to something like "%-12g" would facilitate considerable improvement in reducing the jumping around of the numbers, as well as in providing much more precision. I think that 12 is the max number of characters in g conversion. Or maybe it is 13; I might not have tested negative numbers. The problem is that then it crowds out the other part of the message, the pan/zoom status notification etc. Breaking the message into two lines almost works (so far only checking with gtkagg), but the plot gets resized depending on whether there is a status or not. I think that with some more fiddling around with that part of the toolbar--probably including breaking the message up into separate messages for status and readout, and maybe making the readout use two lines and always be present--we could make the readout and status display much nicer. I have never liked the way it jumps around. Eric > > pylab is so easy and fun to use because the default settings are always > the best one. > IMHO, there is one exception :( > > Xavier > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Hi, I'm trying to add label to a histogram with multiple data. The doc says "label can also be a sequence of strings" but when I try: plt.hist([listA, listB, listC], bins=25, histtype='bar', alpha=0.75,rwidth=0.85,label=['A','B','C']) I got an error: "AttributeError: 'tuple' object has no attribute 'startswith'" (for the entire traceback see http://paste.pocoo.org/show/119820/ ) is it me or a bug? Can I add a legend in another way? thanks in advance! -Yva.
John Hunter wrote: > On Fri, May 29, 2009 at 10:50 AM, Xavier Gnata <xav...@gm...> wrote: > > >>> I had the same problem and fixed it by changing just two lines of code in the axes.py (line 1812 and 1814). Just change the formatter in 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the same for y). >>> > > You don't need to modify the internals of axes.py -- just set the > formatter on the axes instance itself. > > http://matplotlib.sourceforge.net/search.html?q=codex+set_major_formatter > > >> Indeed, but it should really be fixed in the svn. >> > > We could perhaps be a little smarter about this, but consider that one > can easily plot lines over images > > In [30]: imshow(np.random.rand(512,512)) > Out[30]: <matplotlib.image.AxesImage object at 0x151c4f4c> > > In [31]: plot(np.arange(512), np.arange(512)) > > Since the plot can be a mix of images, polygons, lines, etc, it is not > obvious that the formatter should be int. We could trap the case > where you have only an image, no other data, and haven't set the > extent, but it would be complicated because you may add data to the > plot later and we would have to track that we had attempted to be > clever but we should now undo our cleverness. Our general philosophy > is to make is easy for you to customize when the default behavior > doesn't suit you, so try > > import matplotlib.ticker as ticker > ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d')) > .. and ditto for yaxis .. > > in addition to the ticks, you can customize how the coords appear in > the toolbar by setting > > ax.fmt_xdata = ticker.FormatStrFormatter('%d') > ... and ditto for fmt_ydata > > There are a variety of formatters available > > http://matplotlib.sourceforge.net/api/ticker_api.html > > JDH > Hi John, Ok, well; the way I use pylab may be a corner case ;) However, everyone would be happy if the default format would be consistent : As it is, *by default*, when <1000 it displays an int and after 1000 it displays 1.42e3. Why? What do you think this scientific format is a good for? I understand some users would like to see floats by default. Some other users would like to see integers by default. I'm fine with integers or floats by default (I don't cadre) but I don't get the logic of the scientific format. I only would like to see all the digits of the integer parts. I would be fine if I would get 1.422e3 instead of 1.42e3 (we could for instance assume that images larger than (100 000, 100 000) are really a corner case ;)). Why should be the *default* logic so strange? Ok, it is easy to change but the default should at least make sense. As it is, I don't think it does...but there could be a good rational I'm missing. pylab is so easy and fun to use because the default settings are always the best one. IMHO, there is one exception :( Xavier
Thanks, it works well. However, I forgot that computer modern does not include accented characters (unlike latin modern), so I eventually used Stix : mpl.rc('font', family = 'serif', serif = 'STIXGeneral') By the way, is there any way to use Stix for sans-serif as well, or even cursive and monospace ? I don't know how to do that, since Stix seems to contain all of them in a single file (STIXGeneral.ttf) ? Nicolas Michael Droettboom a écrit : > The name of the Computer Modern Roman font that ships with matplotlib > is "cmr10", so > > mpl.rc('font', family = 'serif', serif = 'cmr10') > > should work. > > Mike > > Nicolas Pourcelot wrote: >> Hi, >> >> is there any way to use Computer Modern in any text in matplotlib ? >> >> In http://matplotlib.sourceforge.net/users/customizing.html, I read >> the following : >> >> #font.serif : Bitstream Vera Serif, New Century Schoolbook, >> Century Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 >> L, Times New Roman, Times, Palatino, Charter, serif >> #font.sans-serif : Bitstream Vera Sans, Lucida Grande, Verdana, >> Geneva, Lucid, Arial, Helvetica, Avant Garde, sans-serif >> #font.cursive : Apple Chancery, Textile, Zapf Chancery, Sand, >> cursive >> #font.fantasy : Comic Sans MS, Chicago, Charcoal, Impact, >> Western, fantasy >> #font.monospace : Bitstream Vera Sans Mono, Andale Mono, Nimbus >> Mono L, Courier New, Courier, Fixed, Terminal, monospace >> So, Computer Modern is not listed there. >> >> However, Computer Modern is used in mathtext, so I suppose there is a >> way to use it also in plain text, but I can't figure it... >> >> I tried : >> /mpl.rc('font', family = 'serif', serif = 'computer modern roman')/ >> but it did not work. >> >> Thanks a lot, >> >> Nicolas P. >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >> is a gathering of tech-side developers & brand creativity >> professionals. Meet >> the minds behind Google Creative Lab, Visual Complexity, Processing, >> & iPhoneDevCamp as they present alongside digital heavyweights like >> Barbarian Group, R/GA, & Big Spaceship. >> http://p.sf.net/sfu/creativitycat-com >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >
Gurus, I am implementing some simple Principal Component Analysis (PCA) in Python but I have run into trouble with the graphical output. I have calculated my scores and my loadings (just matrices with mean-centered, univariate values) and I want to scatterplot them. However, to make the graph more useful I want to label each dot in the scatter plot and also color it. I am using Matplotlib, Pylab, and Scipy. For example, given a 3x3 matrix of scores called T, I want to: T,P,E = PCA_svd( X, standardize = True ) t1, t2 = T[:,0], T[:,1] properties = dict( alpha = 0.75, c = some_colors ) s1 = scatter( t1, t2 ,s = 50, **properties ) legend() grid( True ) show() And the result should show three dots of various colors with a legend describing each color, and a data-label (say a two-character code, like AA, BB, CC) for each data-point. I understand that pylab.scatter objects are not formatted correctly to use the pylab.legend command, and I was wondering if a patch has been written for this yet. I use Python 2.5.3 I have found one work-around for the legend that plots each group in color and then hacks with a Rectangle object, as follows: props = dict( alpha = 0.75, faceted = False ) Scores = scatter( t1, t2, c = 'red', s = 50, **props ) Loadings = scatter( p1, p2, c = 'blue', s = 50, **props ) redp = Rectangle( ( 0,0 ), 1, 1, facecolor = 'red' ) bluep = Rectangle( ( 0,0 ), 1, 1, facecolor = 'blue' ) legend( ( redp,bluep ),( 'Scores','Loadings' ) ) grid( True ) show() This works for varying colors across two groups of points, but it doesn't work for single data-points (it says "ValueError: First argument must be a sequence") and it also does not allow me to label each data-point with a two-char code. Any shoves in the right direction would be very much appreciated. Links to online examples and source-code especially so. -Timothy Kinney
Yannick Copin wrote: > Hi, > > I have an error while trying to use mpl.axes.set_default_color_cycle to > define my own color cycle based on the set1 colormap: > > In [1]: set1 = array([[228,55, 77, 152,255,255,166,247,153], > ...: [26, 126,175,78, 127,255,86, 129,153], > ...: [28, 184,74, 163,0, 51, 40, 191,153]],'d').T / 255. > > In [2]: mpl.axes.set_default_color_cycle(set1) > --------------------------------------------------------------------------- > AttributeError Traceback (most recent call last) I just committed a change that should fix this bug. Eric > > /autofs/home/ycopin/<ipython console> in <module>() > > /usr/lib/python2.5/site-packages/matplotlib/axes.py in > set_default_color_cycle(clist) > 113 """ > 114 _process_plot_var_args.defaultColors = clist[:] > --> 115 rcParams['lines.color'] = clist[0] > 116 > 117 class _process_plot_var_args: > > /usr/lib/python2.5/site-packages/matplotlib/__init__.pyc in > __setitem__(self, key, val) > 588 instead.'% (key, alt)) > 589 key = alt > --> 590 cval = self.validate[key](val) > 591 dict.__setitem__(self, key, cval) > 592 except KeyError: > > /usr/lib/python2.5/site-packages/matplotlib/rcsetup.pyc in validate_color(s) > 156 def validate_color(s): > 157 'return a valid color arg' > --> 158 if s.lower() == 'none': > 159 return 'None' > 160 if is_color_like(s): > > AttributeError: 'numpy.ndarray' object has no attribute 'lower' > > I'm using matplotlib 0.98.3 but I checked on the SVN repository that the > offending lines ("rcParams['lines.color'] = clist[0]","if s.lower() == > 'none'") are still there. > > Cheers.
On Fri, May 29, 2009 at 19:09, Neal Becker <ndb...@gm...> wrote: > > from pylab import semilogy, show, grid > grid() > semilogy (result[0]) > > This gave me just a vertical grid. What do I do to get both horiz and vert > grids? (without looking at a screenshot or to the dataset is hard to tell but) is it possible that you have Y values contained in a single logarithmic inteval (or even closer)? if so, there is no line on Y to draw and only vertival lines (relative to X values) are displayed. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
from pylab import semilogy, show, grid grid() semilogy (result[0]) This gave me just a vertical grid. What do I do to get both horiz and vert grids?
On Fri, May 29, 2009 at 10:50 AM, Xavier Gnata <xav...@gm...> wrote: >> I had the same problem and fixed it by changing just two lines of code in the axes.py (line 1812 and 1814). Just change the formatter in 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the same for y). You don't need to modify the internals of axes.py -- just set the formatter on the axes instance itself. http://matplotlib.sourceforge.net/search.html?q=codex+set_major_formatter > Indeed, but it should really be fixed in the svn. We could perhaps be a little smarter about this, but consider that one can easily plot lines over images In [30]: imshow(np.random.rand(512,512)) Out[30]: <matplotlib.image.AxesImage object at 0x151c4f4c> In [31]: plot(np.arange(512), np.arange(512)) Since the plot can be a mix of images, polygons, lines, etc, it is not obvious that the formatter should be int. We could trap the case where you have only an image, no other data, and haven't set the extent, but it would be complicated because you may add data to the plot later and we would have to track that we had attempted to be clever but we should now undo our cleverness. Our general philosophy is to make is easy for you to customize when the default behavior doesn't suit you, so try import matplotlib.ticker as ticker ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d')) .. and ditto for yaxis .. in addition to the ticks, you can customize how the coords appear in the toolbar by setting ax.fmt_xdata = ticker.FormatStrFormatter('%d') ... and ditto for fmt_ydata There are a variety of formatters available http://matplotlib.sourceforge.net/api/ticker_api.html JDH
On Fri, May 29, 2009 at 10:25 AM, Paul Anton Letnes <pau...@gm...> wrote: > I'm trying to make a publication quality plot for a two-column latex > article. I'm using latex for text processing, so the plot quality > itself is impeccable. However, as I scale the plot size down, the > legend becomes extremely large compared to the plot itself. Has > anyone solved this problem in a good manner? I'm not willing to make > do without the legend. The major determinant of the legend is the fontsize, so if you want to make a small figure in inches, you may want to make the legend font smaller import matplotlib.font_manager as font_manager leg = ax.legend(loc='upper left', prop=font_manager.FontProperties(size=10)) JDH
Indeed, but it should really be fixed in the svn. Xavier > Hi Xavier, > > I had the same problem and fixed it by changing just two lines of code in the axes.py (line 1812 and 1814). Just change the formatter in 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the same for y). > > But it would really be great to see your proposal as a standard. > > > Greetings, > > David > > > > -------- Original-Nachricht -------- > Datum: 2009年5月24日 19:15:18 +0200 > Von: Xavier Gnata <xav...@gm...> > An: mat...@li... > Betreff: [Matplotlib-users] x= / y= labels default format is wrong > Hello all, > > I routinely work with images sizes > [1000,1000]. > There is a slight annoying problem whatever the backend I use: > Pixels coordinates default format is wrong. > It does not make sense to display "x=1.42e+03,y=1.92e+03". > Pixels coordinates should be formated *by default* as integers. > > Would it be possible to fix that? > > Steps to reproduce: > import numpy > import pylab > a=numpy.random.random((2000,2000)) > pylab.imshow(a,interpolation='Nearest') > > > Xavier > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >
Hi, I usually fix the size of the figure when I produce it. I use rcparams below for a single column plot. This usually solves the problem. What you see is what you get in the final document if you use the same size of the figure as used to produce it. def paper_single(): plt.rc('figure', figsize=(3.375,3.375)) plt.rc('figure.subplot', left=0.15, right=0.97, bottom=0.1, top=0.95) plt.rc('lines', linewidth=1.5) plt.rc('font', size=10.0) plt.rc('xtick', labelsize='small') plt.rc('ytick', labelsize='small') plt.rc('legend', fontsize='medium') Cheers, Chaitanya On Fri, May 29, 2009 at 5:25 PM, Paul Anton Letnes <pau...@gm...> wrote: > Howdy y'all! > > I'm trying to make a publication quality plot for a two-column latex > article. I'm using latex for text processing, so the plot quality > itself is impeccable. However, as I scale the plot size down, the > legend becomes extremely large compared to the plot itself. Has > anyone solved this problem in a good manner? I'm not willing to make > do without the legend. > > cheers, > Paul. > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >
Howdy y'all! I'm trying to make a publication quality plot for a two-column latex article. I'm using latex for text processing, so the plot quality itself is impeccable. However, as I scale the plot size down, the legend becomes extremely large compared to the plot itself. Has anyone solved this problem in a good manner? I'm not willing to make do without the legend. cheers, Paul.
Hallo Theodore, "Drain, Theodore R" <the...@jp...> writes: > Remember, this is not a multi-threaded system. You can't receive a > second repaint event while the drawing code is happening because the > event loop is not in a separate thread. This is not my choice. If the user resizes the window, the events are created in that manner. And I cannot prevent the user from resizing the window. Best regards Ole
Hi again, Ole Streicher <ole...@gm...> writes: > Darren Dale <dsd...@gm...> writes: >> I am really busy with other things, and can't offer suggestions unless >> you post a short, simple, standalone script that demonstrates the >> problem. > Sure: > w.show() > a.exec_() I forgot to say: execute this code, and then try to resize the window width with the mouse -- this leads to a wrong scrollbar width. Trying to resize the window height with the mouse leads to a wrong scrollbar position. Best regards Ole
Hi Darren, Darren Dale <dsd...@gm...> writes: > I am really busy with other things, and can't offer suggestions unless > you post a short, simple, standalone script that demonstrates the > problem. Sure: --------------------------------8<----------------------------------------- import random import sys from PyQt4 import QtGui, QtCore from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as FigureCanvas from matplotlib.figure import Figure,SubplotParams class DiagramWidget(QtGui.QWidget): def __init__(self, parent): QtGui.QWidget.__init__(self, parent) layout = QtGui.QVBoxLayout(self) self.setLayout(layout) self.diagram = InnerDiagramWidget(self) self.scrollbar = QtGui.QScrollBar(QtCore.Qt.Horizontal, self) layout.addWidget(self.diagram) layout.addWidget(self.scrollbar) def resizeEvent(self, event): print 'figure resize to', event.size() QtGui.QWidget.resizeEvent(self, event) class InnerDiagramWidget(FigureCanvas): def __init__(self, parent): fig = Figure() self.axes = fig.add_subplot(111) range = xrange(10000) l = [ random.randint(-5, 5) for i in range ] self.axes.plot(range, l, drawstyle='steps') FigureCanvas.__init__(self, fig) self.setParent(parent) FigureCanvas.setSizePolicy(self, QtGui.QSizePolicy.Expanding, QtGui.QSizePolicy.Expanding) FigureCanvas.updateGeometry(self) def resizeEvent(self, event): print 'scroll resize to', event.size() FigureCanvas.resizeEvent(self, event) a = QtGui.QApplication(sys.argv) w = QtGui.QMainWindow() w.setCentralWidget(DiagramWidget(w)) w.show() a.exec_() --------------------------------8<----------------------------------------- To see the problem undisturbed, you may remove the "resizeEvent()" functions. Best regards Ole
Hi Darren, On Fri, May 29, 2009 at 01:50, Darren Dale <dsd...@gm...> wrote: > On Thu, May 28, 2009 at 6:01 PM, Sandro Tosi <mo...@de...> wrote: >> >> Hi Darren, >> >> On Thu, May 28, 2009 at 19:16, Darren Dale <dsd...@gm...> wrote: >> > Try the attached script. >> >> Oh it works very great! thanks you very much! >> >> One thing I've done is also remove >> >> import matplotlib >> matplotlib.use('Qt4Agg') >> >> since we're already importing the qt4agg backend directly right after. >> >> One only thing it's left a bit obscure (also because doc is a little >> missing) is this piece of code: >> >> # update the data >> self.line.set_ydata(np.sin(self.x+self.cnt/10.0)) >> # just draw the animated artist >> self.ax.draw_artist(self.line) >> # just redraw the axes rectangle >> self.blit(self.ax.bbox) >> >> first, I've not clear wat draw_artist and blit does, so if you can >> shine some light on me :) >> >> Secondly, the "effect" I'd like to achieve is to update the current >> line values and "replace" the current line with a new one. In this >> code, instead, the line is plotted keeping the previous instances >> around. So the effect is to fil the canvas with sin function plots >> instead of updating only one instance. >> >> Do you know how to "fix" this? > > Not off the top of my head. Maybe someone else on the list can offer a > suggestion. Thanks a lot for your help! Early morning coding did help! :) I'm attaching a script to do what I wanted to. The solution was to remove the animated=True when calling self.ax.plot and then call an explicit self.fig.canvas.draw() - and here it is an animate sin and cos function! :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi