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
(3) |
2
(1) |
3
(3) |
4
(8) |
5
(5) |
6
(1) |
7
(16) |
8
(7) |
9
(29) |
10
(16) |
11
(8) |
12
(8) |
13
(1) |
14
(17) |
15
(15) |
16
(23) |
17
(20) |
18
(25) |
19
(2) |
20
(3) |
21
(12) |
22
(6) |
23
(11) |
24
(6) |
25
(3) |
26
|
27
(2) |
28
(4) |
29
(19) |
30
(5) |
31
(33) |
|
|
Michael Droettboom wrote: > You need to escape the [: > > mpl_pp.xlabel(r"$\[$") > > [] and {} have special meanings in math syntax, so to use them > "literally", they need to be escaped. Really? Note that Matthias had text.usetex=False. I tried various configurations: text.usetex=True xlabel( "$[$") okay xlabel(r"$\[$") okay xlabel( "$\[$") no error, but also no label displayed text.usetex=False xlabel("$[$") failed with Expected end of text (at char 0), (line:1, col:1) xlabel(r"$\[$") xlabel( "$\[$") no error, but displays a star symbol In the last two cases I got a warning mathtext.py:722: MathTextWarning: Unrecognized symbol '\['. Substituting with a dummy symbol. % sym.encode('ascii', 'backslashreplace'), MathTextWarning) Cheers, Manuel > Cheers, > Mike > > Matthias Michler wrote: >> Hello list, >> >> the little example below leads to an error on my system (output is attached). >> I used this some time ago and it worked. Now I'm using the release 0.91.2. >> Is there a reason to use rectangular brackets not in mathtext? >> (same problem occur with '{' for me.) >> >> best regards and thanks in advance for any help, >> Matthias >> ------------------------------------------------------------------------------------------------- >> import matplotlib.pyplot as mpl_pp >> mpl_pp.axes() >> mpl_pp.xlabel("$[$") >> mpl_pp.show() >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >
You need to escape the [: mpl_pp.xlabel(r"$\[$") [] and {} have special meanings in math syntax, so to use them "literally", they need to be escaped. Cheers, Mike Matthias Michler wrote: > Hello list, > > the little example below leads to an error on my system (output is attached). > I used this some time ago and it worked. Now I'm using the release 0.91.2. > Is there a reason to use rectangular brackets not in mathtext? > (same problem occur with '{' for me.) > > best regards and thanks in advance for any help, > Matthias > ------------------------------------------------------------------------------------------------- > import matplotlib.pyplot as mpl_pp > mpl_pp.axes() > mpl_pp.xlabel("$[$") > mpl_pp.show() > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Hello list, the little example below leads to an error on my system (output is attached). I used this some time ago and it worked. Now I'm using the release 0.91.2. Is there a reason to use rectangular brackets not in mathtext? (same problem occur with '{' for me.) best regards and thanks in advance for any help, Matthias ------------------------------------------------------------------------------------------------- import matplotlib.pyplot as mpl_pp mpl_pp.axes() mpl_pp.xlabel("$[$") mpl_pp.show()
Hi Matplotlib users, I'm experiencing some problems when closing a figure (I'm using matplotlib 0.91.0). the function is working correctly when invoked inside the module where it is defined: from pylab import * def test(): t = arange(0.0, 1.0+0.01, 0.01) s = cos(2*2*pi*t) plot(t, s, '-', lw=2) show() print 'after show' if __name__ == '__main__': print test() now if I call test() from another module, the figure closes but show() does not return ('after show' does not get printed) so the execution is stuck. Can somebody shade some light here, I'm really missing something... Thanks a lot Henry
Sorry I didn't notice this right away. This is actually a bug. I made a change so the offset (in scientific notation) is written in the same font as the other tick values, which unfortunately broke with the default fonts. I have attached a patch against 0.91.2. This will make it into the next 0.91.x bugfix release, but that may be a while. Cheers, Mike Matthias Michler wrote: > Hello Mike, Hello list, > > thanks for your reply. > > On Wednesday 09 January 2008 17:58, Michael Droettboom wrote: >> The default mathtext font should have the "times" symbol. Are you >> making any other changes that would affect the selection of mathtext >> fonts? > I don't think that I changed anything. I only run the script attached in the > last email. >> (Can you please attach a copy of your matplotlibrc file?) If >> that looks ok, perhaps it isn't finding the math fonts correctly. > I attached the file. >> There >> are a multitude of reasons that could be happening. It is sometimes >> helpful to set "verbose.level" to "debug-annoying" and then look at the >> logs to see what might be going on. Also, you could try deleting the >> fonts cache in ~/.matplotlib/fontManager.cache to force it to regenerate. > > I deleted the ~/.matplotlib/fontManager.cache and run again my script. The > output with "verbose.level : debug-annoying" is attached, but I don't > understand what I'm doing wrong. > Maybe my matplotlibrc is to old to be used with the last improvements, > although I can't see any substantial differences. > > Thanks in advance for any further suggestions. > best regards, > Matthias > >> Cheers, >> Mike >> >> Matthias Michler wrote: >>> Hello list, >>> >>> the little example below seems to fail, can anybody help me? >>> I'm on Debian using the release 0.91.2. >>> >>> best regards and thanks in advance for any hints, >>> Matthias >>> >>> ------------------------------------------------------------------------- >>> ------------------ from matplotlib.ticker import ScalarFormatter >>> from matplotlib.pyplot import * >>> >>> ax = axes() >>> axis([0.0, 10**-7, 0, 10**-7]) >>> >>> ax.yaxis.set_major_formatter(ScalarFormatter(useMathText=True)) >>> >>> show() >>> ------------------------------------------------------------------------- >>> ----------------------- error message: >>> /scratch/michler/SOFT/lib/python2.4/site-packages/matplotlib/mathtext.py: >>> 722: MathTextWarning: Unrecognized symbol '\times'. Substituting with a >>> dummy symbol. >>> % sym.encode('ascii', 'backslashreplace'), MathTextWarning) >>> >>> >>> the string '\times' is due to line >>> sciNotStr = r'{\times}'+self.format_data(10**self.orderOfMagnitude) >>> in function ScalarFormatter.get_offset >>> >>> ------------------------------------------------------------------------- >>> Check out the new SourceForge.net Marketplace. >>> It's the best place to buy or sell services for >>> just about anything Open Source. >>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl >>> ace _______________________________________________ >>> Matplotlib-users mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------- >>> Check out the new SourceForge.net Marketplace. >>> It's the best place to buy or sell services for >>> just about anything Open Source. >>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Matplotlib-users mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Gio...@ma... wrote: > matalb has a gscatter command that work like this" > > GSCATTER(X,Y,G) creates a scatter plot of the vectors X and Y > grouped by G. Points with the same value of G are shown with > the same color and marker. G is a grouping variable defined as > a vector, a cell array of strings, or a string matrix, and it > must have the same number of rows as X and Y. Alternatively > G can be a cell array of grouping variables (such as {G1 G2 G3}) > to group the values in X by each unique combination of grouping > variable values. > > GSCATTER(X,Y,G,CLR,SYM,SIZ) specifies the colors, markers, and > size to use. CLR is either a string of color specifications or > a three-column matrix of color specifications. SYM is a string > of marker specifications. Type "help plot" for more information. > For example, if SYM='o+x', the first group will be plotted with a > circle, the second with plus, and the third with x. SIZ is a > marker size to use for all plots. By default, the marker is '.'. > > GSCATTER(X,Y,G,CLR,SYM,SIZ,DOLEG) lets you control whether legends > are created. Set DOLEG to 'on' (default) or 'off'. > > GSCATTER(X,Y,G,CLR,SYM,SIZ,DOLEG,XNAM,YNAM) specifies XNAM and > YNAM as the names of the X and Y variables. Each must be a > character string. If you omit XNAM and YNAM, GSCATTER attempts to > determine the names of the variables passed in as the first and > second arguments. > > H = GSCATTER(...) returns an array of handles to the objects > created. > > Example: Scatter plot of car data coded by country. > load carsmall > gscatter(Weight, MPG, Origin) > > See also grpstats, grp2idx." > > it's very very useful instead of doing multiple scatter and merging them > togheter. I think it can be easily implemented but i don't know how much > request there is for it. > > > Giorgio > I don't think something like that work in matplotlib with scatter for the marker parameter. But it's possible to use an array of sizes and colors, ie. s = [20,30,40] x = arange(3) y = arange(3) scatter(x,y,s=s) See scatter doc string: Arguments s and c can also be given as kwargs; this is encouraged for readability. s is a size in points^2. It is a scalar or an array of the same length as x and y. c is a color and can be a single color format string, or a sequence of color specifications of length N, or a sequence of N numbers to be mapped to colors using the cmap and norm specified via kwargs (see below). Note that c should not be a single numeric RGB or RGBA sequence because that is indistinguishable from an array of values to be colormapped. c can be a 2-D array in which the rows are RGB or RGBA, however. Manuel
Gio...@ma... wrote: > Thanks ! i didn't know that. > Do you know also if it is possible to have something similar to a scatter > group ? Sorry, but what do you mean by "scatter group" ? > Thanks > Giorgio
Hello Mike, Hello list, thanks for your reply. On Wednesday 09 January 2008 17:58, Michael Droettboom wrote: > The default mathtext font should have the "times" symbol. Are you > making any other changes that would affect the selection of mathtext > fonts? I don't think that I changed anything. I only run the script attached in the last email. > (Can you please attach a copy of your matplotlibrc file?) If > that looks ok, perhaps it isn't finding the math fonts correctly. I attached the file. > There > are a multitude of reasons that could be happening. It is sometimes > helpful to set "verbose.level" to "debug-annoying" and then look at the > logs to see what might be going on. Also, you could try deleting the > fonts cache in ~/.matplotlib/fontManager.cache to force it to regenerate. I deleted the ~/.matplotlib/fontManager.cache and run again my script. The output with "verbose.level : debug-annoying" is attached, but I don't understand what I'm doing wrong. Maybe my matplotlibrc is to old to be used with the last improvements, although I can't see any substantial differences. Thanks in advance for any further suggestions. best regards, Matthias > Cheers, > Mike > > Matthias Michler wrote: > > Hello list, > > > > the little example below seems to fail, can anybody help me? > > I'm on Debian using the release 0.91.2. > > > > best regards and thanks in advance for any hints, > > Matthias > > > > ------------------------------------------------------------------------- > >------------------ from matplotlib.ticker import ScalarFormatter > > from matplotlib.pyplot import * > > > > ax = axes() > > axis([0.0, 10**-7, 0, 10**-7]) > > > > ax.yaxis.set_major_formatter(ScalarFormatter(useMathText=True)) > > > > show() > > ------------------------------------------------------------------------- > >----------------------- error message: > > /scratch/michler/SOFT/lib/python2.4/site-packages/matplotlib/mathtext.py: > >722: MathTextWarning: Unrecognized symbol '\times'. Substituting with a > > dummy symbol. > > % sym.encode('ascii', 'backslashreplace'), MathTextWarning) > > > > > > the string '\times' is due to line > > sciNotStr = r'{\times}'+self.format_data(10**self.orderOfMagnitude) > > in function ScalarFormatter.get_offset > > > > ------------------------------------------------------------------------- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl > >ace _______________________________________________ > > Matplotlib-users mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Hi, you are limited to 10 "named" symbols. But you can use much more symbols with scatter !!! Have a look at examples/scatter_star_symbols.py. You can use: pylab.scatter(x,y,marker=(5,0)) produces a 5-sided regular polygon. pylab.scatter(x,y,marker=(5,1)) produces a starlike polygon pylab.scatter(x,y,marker=(5,2)) produces an asterisk. You can even define your own symbols by defining the vertices of a polygon: verts = zip( [x1,x2,x3...], [y1,y2,y3,...]) pylab.scatter(x,y,marker=(verts,0)) Note that there is a third, optional parameter for the marker keyword, ie. marker=(5,0,math.pi/4.) that defines the rotation of a symbol. Manuel Gio...@ma... wrote: > I was wondering if there exist a functino like Matlab (TM) gscatter in > matplot lib but I coulnd't find one. > I also seen that in matplot lib we are "limited" to 10 symbols in scatter > while in MT we have 13 (and I have to plot 12 :))) > is it possible to implement the new function (gscatter) and other symbols > ;) > thanks > Giorgio > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
I was wondering if there exist a functino like Matlab (TM) gscatter in matplot lib but I coulnd't find one. I also seen that in matplot lib we are "limited" to 10 symbols in scatter while in MT we have 13 (and I have to plot 12 :))) is it possible to implement the new function (gscatter) and other symbols ;) thanks Giorgio
On Wednesday 09 January 2008 8:50:46 pm Charlie Moad wrote: > On Jan 9, 2008 10:35 AM, Darren Dale <dar...@co...> wrote: > > On Wednesday 09 January 2008 10:15:54 am Francesco Pretto wrote: > > > 2008年1月9日, Darren Dale <dar...@co...>: > > > > setup.py attempts to select the appropriate backend for you, based on > > > > what backends were available at build time. That selection is written > > > > into the default matplotlibrc file, which resides in > > > > site-packages/matplotlib/mpl-data. If matplotlib finds another > > > > matplotlibrc file (for example, in the current working directory, in > > > > $HOME/.matplotlib, etc), then it will use those settings instead. I > > > > would guess that is the source of the problem. > > > > > > No, the problem is the default installed matplotlibrc, that is not > > > different from the one present in the source tree and has the default > > > selection: > > > > > > backend : TkAgg > > > > > > Now, i don't know if the build script is trying to modify it according > > > user selection or compile-time backend detection, but I'm wondering > > > why the same problem wasn't happening on linux, where I tipically > > > never install Tk runtime. > > > > > > However, for me the problem is solved, but if there's a matplotlib > > > windows dev listening, here is my experience; first, i removed the > > > already installed "lib/site-packages/matplotlib/mpl-data/matplotlibrc" > > > . Afer, I went for clean compiling with a setup.cfg with these > > > configurations: > > > > > > gtk = True > > > gtkagg = False > > > tkagg = False > > > wxagg = False > > > backend = GTK > > > > > > Eventually, "python setup.py install" write again a > > > "site-packages/matplotlib/mpl-data/matplotlibrc" which still have: > > > > > > backend : TkAgg > > > > > > If this shouldn't happen, well, consider this a bug report :D > > > > Oh, I see. Look at line 238 in setup.py. Maybe we don't need that check > > for sys.platform anymore, now that we have setup.cfg. I think that check > > was in there for the benefit of building the windows installers, which we > > wanted to default to tkagg. > > > > I think it would be best to use a setup.cfg to set the numerix and > > backends when building the windows installers. Charlie, does that sound > > alright? > > That's fine. I didn't use setup.cfg for the latest binaries though. That is no problem. If you had, the binaries would not be any different than they are now. I'll make the change tomorrow, and send you the appropriate setup.cfg for building the windows installer. Darren
On Jan 9, 2008 10:35 AM, Darren Dale <dar...@co...> wrote: > > On Wednesday 09 January 2008 10:15:54 am Francesco Pretto wrote: > > 2008年1月9日, Darren Dale <dar...@co...>: > > > setup.py attempts to select the appropriate backend for you, based on > > > what backends were available at build time. That selection is written > > > into the default matplotlibrc file, which resides in > > > site-packages/matplotlib/mpl-data. If matplotlib finds another > > > matplotlibrc file (for example, in the current working directory, in > > > $HOME/.matplotlib, etc), then it will use those settings instead. I would > > > guess that is the source of the problem. > > > > No, the problem is the default installed matplotlibrc, that is not > > different from the one present in the source tree and has the default > > selection: > > > > backend : TkAgg > > > > Now, i don't know if the build script is trying to modify it according > > user selection or compile-time backend detection, but I'm wondering > > why the same problem wasn't happening on linux, where I tipically > > never install Tk runtime. > > > > However, for me the problem is solved, but if there's a matplotlib > > windows dev listening, here is my experience; first, i removed the > > already installed "lib/site-packages/matplotlib/mpl-data/matplotlibrc" > > . Afer, I went for clean compiling with a setup.cfg with these > > configurations: > > > > gtk = True > > gtkagg = False > > tkagg = False > > wxagg = False > > backend = GTK > > > > Eventually, "python setup.py install" write again a > > "site-packages/matplotlib/mpl-data/matplotlibrc" which still have: > > > > backend : TkAgg > > > > If this shouldn't happen, well, consider this a bug report :D > > Oh, I see. Look at line 238 in setup.py. Maybe we don't need that check for > sys.platform anymore, now that we have setup.cfg. I think that check was in > there for the benefit of building the windows installers, which we wanted to > default to tkagg. > > I think it would be best to use a setup.cfg to set the numerix and backends > when building the windows installers. Charlie, does that sound alright? That's fine. I didn't use setup.cfg for the latest binaries though.
Darren, This is interesting. I tried to get a screenshot of the bad behavior for you. My first attempt was to just hit "print screen". Under Fedora Core 8, KDE window manager this brings up the application KSnapshot. When KSnapshot gets focus, the bad behavior goes away and it was not captured in the screenshot. I did notice the KSnapshot app has a snapshot delay feature. I set it to 2 seconds, and clicked new snapshot. The KSnapshot window disappeared for 2 seconds; the bad behavior was back for that period of time. However, even in this case, the behavior doesn't show up in the screenshot. This makes me wonder if maybe it is a video driver problem. Linux has the right colors in memory (which is I assume the level at which the snap shot is taken), but the driver is wigging out when communicating the info to the actual video card. If I manage to get a SS I will post it. -Dan -----Original Message----- From: Darren Dale [mailto:dar...@co...] Sent: Wednesday, January 09, 2008 3:08 PM To: mat...@li... Cc: Dan Karipides Subject: Re: [Matplotlib-users] screen colors invert with matplotlib Could you please post a screenshot of the bad behavior? I don't see anything strange here, and I'm using qt-4.3.3, pyqt-4.3.3, and an nvidia GeForce 6600. Darren On Wednesday 09 January 2008 05:00:28 pm Dan Karipides wrote: > Do the demo apps come with the standard qt4/pyqt4 install? I just used the > Fedora Core 8 package manager to install both of these packages. > > I apologize that my knowledge of qt is limited. I'll do some investigation > of qt4 / pyqt4 on my own before bothering the list further. > > Thanks for the suggestion, > > -Dan > > -----Original Message----- > From: Michael Droettboom [mailto:md...@st...] > Sent: Wednesday, January 09, 2008 2:35 PM > To: Dan Karipides > Cc: 'Matplotlib Users' > Subject: Re: [Matplotlib-users] screen colors invert with matplotlib > > I wonder if the problem exhibits itself in any other pyqt4 apps (such as > the demo apps)... In that case, I would take your question to the pyqt > list. Otherwise, we'll want to track down what specifically matplotlib > is doing that causes this. > > Cheers, > Mike >
Could you please post a screenshot of the bad behavior? I don't see anything strange here, and I'm using qt-4.3.3, pyqt-4.3.3, and an nvidia GeForce 6600. Darren On Wednesday 09 January 2008 05:00:28 pm Dan Karipides wrote: > Do the demo apps come with the standard qt4/pyqt4 install? I just used the > Fedora Core 8 package manager to install both of these packages. > > I apologize that my knowledge of qt is limited. I'll do some investigation > of qt4 / pyqt4 on my own before bothering the list further. > > Thanks for the suggestion, > > -Dan > > -----Original Message----- > From: Michael Droettboom [mailto:md...@st...] > Sent: Wednesday, January 09, 2008 2:35 PM > To: Dan Karipides > Cc: 'Matplotlib Users' > Subject: Re: [Matplotlib-users] screen colors invert with matplotlib > > I wonder if the problem exhibits itself in any other pyqt4 apps (such as > the demo apps)... In that case, I would take your question to the pyqt > list. Otherwise, we'll want to track down what specifically matplotlib > is doing that causes this. > > Cheers, > Mike > > Dan Karipides wrote: > > Thanks John. > > > > I did this test: > > > > python simple_plot.py -dTkAgg > > > > and it worked just fine. (The GTK backend won't compile for me, but that > > is > > > a topic for another email.) > > > > So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I > > guess. > > > > At least I know where to look now. > > > > -Dan > > > > -----Original Message----- > > From: John Hunter [mailto:jd...@gm...] > > Sent: Wednesday, January 09, 2008 11:40 AM > > To: Dan Karipides > > Cc: Matplotlib Users > > Subject: Re: [Matplotlib-users] screen colors invert with matplotlib > > > > On Jan 9, 2008 10:14 AM, Dan Karipides <ka...@tx...> wrote: > >> OS: Fedora Core 8 > >> > >> Video Card: Nvidia GeForce 8800 Ultra > >> > >> Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20, > > > > 2007) > > > >> Matplotlib version: matplotlib-0.91.2.tar.gz (built from source) > >> > >> Backend chosen: qt4agg > > > > Hi Dan, > > > > No one has ever reported anything like this before as far as I know. > > Could you try running a simple test script with a different GUI > > backend, eg tkagg or gtkagg > > > > > python simple_plot.py -dTkAgg #or GTKAgg > > > > I assume this is a qt4 problem, but I'd just like to confirm before we > > proceed. Do you see it with qtagg or just qt4agg? > > > > > > ------------------------------------------------------------------------- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplac >e > > > _______________________________________________ > > Matplotlib-users mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Darren S. Dale, Ph.D. Staff Scientist Cornell High Energy Synchrotron Source Cornell University 275 Wilson Lab Rt. 366 & Pine Tree Road Ithaca, NY 14853 dar...@co... office: (607) 255-3819 fax: (607) 255-9001 http://www.chess.cornell.edu
Do the demo apps come with the standard qt4/pyqt4 install? I just used the Fedora Core 8 package manager to install both of these packages. I apologize that my knowledge of qt is limited. I'll do some investigation of qt4 / pyqt4 on my own before bothering the list further. Thanks for the suggestion, -Dan -----Original Message----- From: Michael Droettboom [mailto:md...@st...] Sent: Wednesday, January 09, 2008 2:35 PM To: Dan Karipides Cc: 'Matplotlib Users' Subject: Re: [Matplotlib-users] screen colors invert with matplotlib I wonder if the problem exhibits itself in any other pyqt4 apps (such as the demo apps)... In that case, I would take your question to the pyqt list. Otherwise, we'll want to track down what specifically matplotlib is doing that causes this. Cheers, Mike Dan Karipides wrote: > Thanks John. > > I did this test: > > python simple_plot.py -dTkAgg > > and it worked just fine. (The GTK backend won't compile for me, but that is > a topic for another email.) > > So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I > guess. > > At least I know where to look now. > > -Dan > > -----Original Message----- > From: John Hunter [mailto:jd...@gm...] > Sent: Wednesday, January 09, 2008 11:40 AM > To: Dan Karipides > Cc: Matplotlib Users > Subject: Re: [Matplotlib-users] screen colors invert with matplotlib > > On Jan 9, 2008 10:14 AM, Dan Karipides <ka...@tx...> wrote: > >> OS: Fedora Core 8 >> >> Video Card: Nvidia GeForce 8800 Ultra >> >> Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20, > 2007) >> Matplotlib version: matplotlib-0.91.2.tar.gz (built from source) >> >> Backend chosen: qt4agg >> > > Hi Dan, > > No one has ever reported anything like this before as far as I know. > Could you try running a simple test script with a different GUI > backend, eg tkagg or gtkagg > > > python simple_plot.py -dTkAgg #or GTKAgg > > I assume this is a qt4 problem, but I'd just like to confirm before we > proceed. Do you see it with qtagg or just qt4agg? > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
I don't have pyqt installed, just pyqt4, so I'm afraid I can't do that test for you at the moment. Though I suppose I could install pyqt as one method of testing this. Thanks, -Dan -----Original Message----- From: John Hunter [mailto:jd...@gm...] Sent: Wednesday, January 09, 2008 2:32 PM To: Dan Karipides; Matplotlib Users Subject: Re: [Matplotlib-users] screen colors invert with matplotlib On Jan 9, 2008 1:32 PM, Dan Karipides <ka...@tx...> wrote: > Thanks John. > > I did this test: > > python simple_plot.py -dTkAgg > > and it worked just fine. (The GTK backend won't compile for me, but that is > a topic for another email.) > > So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I > guess. > > At least I know where to look now. What about qtagg vs qt4agg? It would be interesting to know if it is qt4 specific, or qt specific. Please keep the responses on list because there are other developers more knowledgeable than I about qt. JDH
I wonder if the problem exhibits itself in any other pyqt4 apps (such as the demo apps)... In that case, I would take your question to the pyqt list. Otherwise, we'll want to track down what specifically matplotlib is doing that causes this. Cheers, Mike Dan Karipides wrote: > Thanks John. > > I did this test: > > python simple_plot.py -dTkAgg > > and it worked just fine. (The GTK backend won't compile for me, but that is > a topic for another email.) > > So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I > guess. > > At least I know where to look now. > > -Dan > > -----Original Message----- > From: John Hunter [mailto:jd...@gm...] > Sent: Wednesday, January 09, 2008 11:40 AM > To: Dan Karipides > Cc: Matplotlib Users > Subject: Re: [Matplotlib-users] screen colors invert with matplotlib > > On Jan 9, 2008 10:14 AM, Dan Karipides <ka...@tx...> wrote: > >> OS: Fedora Core 8 >> >> Video Card: Nvidia GeForce 8800 Ultra >> >> Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20, > 2007) >> Matplotlib version: matplotlib-0.91.2.tar.gz (built from source) >> >> Backend chosen: qt4agg >> > > Hi Dan, > > No one has ever reported anything like this before as far as I know. > Could you try running a simple test script with a different GUI > backend, eg tkagg or gtkagg > > > python simple_plot.py -dTkAgg #or GTKAgg > > I assume this is a qt4 problem, but I'd just like to confirm before we > proceed. Do you see it with qtagg or just qt4agg? > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Jan 9, 2008 1:32 PM, Dan Karipides <ka...@tx...> wrote: > Thanks John. > > I did this test: > > python simple_plot.py -dTkAgg > > and it worked just fine. (The GTK backend won't compile for me, but that is > a topic for another email.) > > So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I > guess. > > At least I know where to look now. What about qtagg vs qt4agg? It would be interesting to know if it is qt4 specific, or qt specific. Please keep the responses on list because there are other developers more knowledgeable than I about qt. JDH
Thanks John. I did this test: python simple_plot.py -dTkAgg and it worked just fine. (The GTK backend won't compile for me, but that is a topic for another email.) So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I guess. At least I know where to look now. -Dan -----Original Message----- From: John Hunter [mailto:jd...@gm...] Sent: Wednesday, January 09, 2008 11:40 AM To: Dan Karipides Cc: Matplotlib Users Subject: Re: [Matplotlib-users] screen colors invert with matplotlib On Jan 9, 2008 10:14 AM, Dan Karipides <ka...@tx...> wrote: > OS: Fedora Core 8 > > Video Card: Nvidia GeForce 8800 Ultra > > Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20, 2007) > > Matplotlib version: matplotlib-0.91.2.tar.gz (built from source) > > Backend chosen: qt4agg > Hi Dan, No one has ever reported anything like this before as far as I know. Could you try running a simple test script with a different GUI backend, eg tkagg or gtkagg > python simple_plot.py -dTkAgg #or GTKAgg I assume this is a qt4 problem, but I'd just like to confirm before we proceed. Do you see it with qtagg or just qt4agg?
Included below is an updated patch fixing the legend with numpoints=1. The patch has been made against SVN and works for Line2D, LineCollection, Patch, and RegularPolyCollection. The patch could be merged. I also think the patch could be improved. Currently, handle._marker is examined to determine if the legend should contain lines or symbols, but this is done in the _get_handles function. It would be better if that could be moved into the Legend class definition, however, I do not know how to examine handle._marker in the Legend class definition. Again, I would appreciate any comments or improvements. Thanks, Paul diff -u a/lib/matplotlib/legend.py b/lib/matplotlib/legend.py --- a/lib/matplotlib/legend.py 2008年01月09日 13:11:00.000000000 -0600 +++ b/lib/matplotlib/legend.py 2008年01月09日 13:08:36.000000000 -0600 @@ -175,9 +175,7 @@ # make a trial box in the middle of the axes. relocate it # based on it's bbox left, top = 0.5, 0.5 - if self.numpoints == 1: - self._xdata = npy.array([left + self.handlelen*0.5]) - else: + if self.numpoints > 1: self._xdata = npy.linspace(left, left + self.handlelen, self.numpoints) textleft = left+ self.handlelen+self.handletextsep self.texts = self._get_texts(labels, textleft, top) @@ -236,6 +234,7 @@ def _get_handles(self, handles, texts): HEIGHT = self._approx_text_height() + left = 0.5 ret = [] # the returned legend lines @@ -243,6 +242,10 @@ x, y = label.get_position() x -= self.handlelen + self.handletextsep if isinstance(handle, Line2D): + if self.numpoints == 1 and handle._marker == 'None': + self._xdata = npy.linspace(left, left + self.handlelen, 2) + elif self.numpoints == 1: + self._xdata = npy.array([left + self.handlelen*0.5]) ydata = (y-HEIGHT/2)*npy.ones(self._xdata.shape, float) legline = Line2D(self._xdata, ydata) legline.update_from(handle) @@ -253,7 +256,8 @@ ret.append(legline) elif isinstance(handle, Patch): - + if self.numpoints == 1: + self._xdata = npy.linspace(left, left + self.handlelen, 2) p = Rectangle(xy=(min(self._xdata), y-3/4*HEIGHT), width = self.handlelen, height=HEIGHT/2, ) @@ -263,6 +267,8 @@ p.set_clip_path(None) ret.append(p) elif isinstance(handle, LineCollection): + if self.numpoints == 1: + self._xdata = npy.linspace(left, left + self.handlelen, 2) ydata = (y-HEIGHT/2)*npy.ones(self._xdata.shape, float) legline = Line2D(self._xdata, ydata) self._set_artist_props(legline) @@ -277,6 +283,8 @@ ret.append(legline) elif isinstance(handle, RegularPolyCollection): + if self.numpoints == 1: + self._xdata = npy.array([left]) p = Rectangle(xy=(min(self._xdata), y-3/4*HEIGHT), width = self.handlelen, height=HEIGHT/2, ) Michael Droettboom wrote: > I'm sure the radio silence to your question is just due to holidays. > > Thanks for looking into this. I'd be happy to incorporate your patch > when it is ready. > > As for your question about plots that can include patches -- patches are > virtually anything plotted that aren't lines or images. This includes > rectangles, polygons and ellipses, for instance. See something like > ellipse_demo.py for an example. Patches are always drawn as rectangles > in the legend. > > Cheers, > Mike >
On Jan 9, 2008 9:11 AM, Michael Droettboom <md...@st...> wrote: > You could comment out these two lines: > > x = (int)x + 0.5; > y = (int)y + 0.5; > > and see if that corrects your wiggliness problem, just to confirm that > as the source. > > The bigger question is -- there was probably a good reason that this > code was put in there in the first place, so it probably isn't a good > idea to remove it en masse. It may need to be exposed as an argument so > some things get this behavior and others don't. I know that dashed > lines that are perpendicular to the edges of the figure (e.g. grid > lines) look much worse if they aren't rounded to pixel centers. But in > general for polygons, I don't know if that's true. For subpixel accuracy in rendering, agg antialiasing causes different line segments to appear different in their thicknesses if they do not have the same subpixel values. Maxim wrote the following essay on the subject: http://antigrain.com/tips/line_alignment/line_alignment.agdoc.html#PAGE_LINE_ALIGNMENT For this reason, to preserve visible consistency of the segments, I have several parts in the agg code which snaps the vertices ot the pixel centers. I have never found a solution that seems to work in all cases, since removing the snapto code will cause the inconsistencies referred to above. I think should probably be a graphics context property (which could get the information from an artist property) so at least the user could control it when needed. JDH
On Jan 9, 2008 10:14 AM, Dan Karipides <ka...@tx...> wrote: > OS: Fedora Core 8 > > Video Card: Nvidia GeForce 8800 Ultra > > Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20, 2007) > > Matplotlib version: matplotlib-0.91.2.tar.gz (built from source) > > Backend chosen: qt4agg > Hi Dan, No one has ever reported anything like this before as far as I know. Could you try running a simple test script with a different GUI backend, eg tkagg or gtkagg > python simple_plot.py -dTkAgg #or GTKAgg I assume this is a qt4 problem, but I'd just like to confirm before we proceed. Do you see it with qtagg or just qt4agg?
I've recently started using matplotlib on new unix box and I'm running in to an odd problem. I'm not sure what the root cause is (my linux installation, graphics drivers, matplotlib, or something else) but I thought I would ask here to see if anyone else had experienced this. OS: Fedora Core 8 Video Card: Nvidia GeForce 8800 Ultra Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20, 2007) Matplotlib version: matplotlib-0.91.2.tar.gz (built from source) Backend chosen: qt4agg Qt4 version: 4.3.3 The problem: If a matplotlib plot window ever has focus, the screen colors on the whole screen invert themselves. White becomes black, etc. I can probably post a link to a screenshot if that will help, but it looks like a simple color inversion to me. If the plot window doesn't have focus, everything is drawn correctly. My simple test was: $ ipython -pylab In [1]: plot(range(10)) With older versions of matplotlib, the colors did not invert-the screen went totally black when the plot window had focus. When it doesn't, everything looks fine. I'm not seeing this behavior with any other application so far. If upgrading to the SVN trunk version would help, I'm willing to give that a try. But I wanted to get some feedback before updating anything else. Thanks, -Dan ----- Dan Karipides Tech-X Corporation ka...@tx...
Michael Droettboom wrote: > Thanks for the patch. However, perhaps a more general solution would be > to use the Python locale module to format numbers according to different > locales. And expose a kwarg select between the user's preferred locale, > the current U.S. English-centric defaults as they are now, or an > arbitrary locale using an ISO language code. That seems like it could > be a better long-term solution, since there are different number formats > all over, not just in Germany. > > All that said, internationalization is hard -- especially for us > sheltered people in the U.S. where the defaults are most often correct. > I may be missing an important detail here. > > Cheers, > Mike Mike, I agree that this problem needs to be solved. I was looking at it a year or so ago, with the idea of putting in simple options rather than full internationalization, but I never followed up on it. Until your message I had never looked at the documentation for the locale module. It *might* be possible to fix the formatters by replacing a few "somestring % variables" constructs with calls to locale.format_string(somestring, variables)--but this is new in python 2.5. Without this it looks like it might be much harder. The formatter code is already a bit convoluted because of all the variations--latex, mathtex, plain, with or without scientific notation. Actually, I think the option I was looking at a year ago was what is handled by the "grouping" arg in locale.format_string--the ability to use commas or dots to break up triplets of digits. Eric
Thanks for the patch. However, perhaps a more general solution would be to use the Python locale module to format numbers according to different locales. And expose a kwarg select between the user's preferred locale, the current U.S. English-centric defaults as they are now, or an arbitrary locale using an ISO language code. That seems like it could be a better long-term solution, since there are different number formats all over, not just in Germany. All that said, internationalization is hard -- especially for us sheltered people in the U.S. where the defaults are most often correct. I may be missing an important detail here. Cheers, Mike Thorsten Kranz wrote: > Hi list, Hi Matthias, > > I found another way to deal with this problem. when defining the > colorbar, one can give an additional kwarg "format", so by defining the > kwarg "format=formatter", we solved the problem. > > Anyway, I think an option as Matthias implemented would be very handy > for all those users like us here in Germany who might want to have the > numbers formatted with commata. > > Greetings, > Thorsten > > 2008年1月9日, Matthias Michler <Mat...@gm... > <mailto:Mat...@gm...>>: > > Hello list, > Hello Thorsten, > > On Wednesday 09 January 2008 11:38, Thorsten Kranz wrote: > > I have a question concerning reformatting of axis-ticks via the > > FuncFormatter-class. In german, it's common to use a comma as > separator for > > decimal numbers instead of a dot. To realize it in matplotlib, I do > > something like > > > > >from matplotlib.ticker import FuncFormatter > > > > import pylab > > pylab.figure() > > formatter = FuncFormatter(lambda x,pos: ("%.2f"%x).replace(".",",")) > > ax = pylab.axes() > > ax.xaxis.set_major_formatter(formatter) > > ax.yaxis.set_major_formatter(formatter) > > ax.plot(pylab.arange(0,1,0.1),pylab.arange(0,1,0.1)) > > This works fine for me, > > I had the same idea ;-). The problem is that you have a fixed number > of digits > behind the comma, which is not the desirable behaviour during zoom. > I changed the ticker.py/ axes.py files to circumwait this > disadvantage. I > attached a patch showing my changes and maybe somebody can test it. > You can activate it using: > ax.ticklabel_format(style='comma') > for an ScalarFormatter > > > but I encounter a problem when I do an > > imshow-command with a colorbar. In the imshow-axes, it's o.k., > but for the > > colorbar it doesn't really work. I do > > > > cb = pylab.colorbar() > > cb.ax.yaxis.set_major_formatter(formatter) > > > > and, actually, all dots are replaced by com9mata, but the values > are also > > changed! E.g. instead of the old values (without formatter) from > 0-0.54, > > the > > > > values are increased to 0-0.95. > [...] > > Can anyone explain why it doesn't work out as I expect it to work? > I don't know were the problem comes from. I attached your example in > a slitly > modified version and this shows that the problem is not due to your > special > formatting. It occurs with matplotlib.ticker.ScalarFormatter, too. > > best regards, > Matthias > > > Or is there a better, more standard way to substitute the dots by > commata? > > > > Thanks, > > Thorsten > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > <https://lists.sourceforge.net/lists/listinfo/matplotlib-users> > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA