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
(22) |
3
(8) |
4
(10) |
5
(1) |
6
|
7
(11) |
8
(4) |
9
(14) |
10
(18) |
11
(18) |
12
(2) |
13
(8) |
14
(14) |
15
(6) |
16
(8) |
17
(9) |
18
(9) |
19
(7) |
20
(8) |
21
(8) |
22
(14) |
23
(10) |
24
(11) |
25
(17) |
26
(1) |
27
(3) |
28
(12) |
|
|
|
|
|
From: John H. <jdh...@ac...> - 2005-02-28 23:53:31
|
>>>>> "Robert" == Robert Leftwich <ro...@le...> writes: Robert> When attempting to generate a larger number of graph sets Robert> (i.e. 3 graphs of similar style over different data Robert> ranges), I'm intermittently getting a GPF on XP in Robert> na_backend_agg.pyd according to the report that M$ offers Robert> to send to itself. Ouch. Robert> It is repeatable in one sense, in that if I restart the Robert> graph generation from the beginning it will fail at the Robert> same set, but if skip the first set of graphs it doesn't Robert> produce one additional set and then die, it dies at 15 (5 Robert> sets) earlier. I can restart from any of the sets where it Robert> failed and it will continue on for some random number Robert> before GPF'ing again - anything from 9 thru to 150 graphs Robert> or so. Repeatable is good. Standalone much better. So you are running the pure Agg backend (no GUI?). It would help to post the output of c:> python myscript.py --verbose-helpful Robert> If I use Numeric (23.7, the latest) it is a lot worse - Robert> meaning fewer sets before failure. Also matplotlib 0.72 Robert> was a lot worse with either Numeric and numarray. It probably won't happen with 0.71 and this would be worth testing. I did a bunch of changes in backend agg in 0.72, including using the numeric API rather than the sequence protocol. If you want to verify that the problem was introduced in 0.72 (which will help me narrow down the possible culprits) remove site-packages/matplotlib and then install 0.71 and see if the crash disappears. Robert> I'm not sure of the best way to proceed from here - is Robert> this a known issue or related to one or should I attempt Robert> to produce a standalone test that causes the problem? That would help immensely. One thing I can do is send you a debug build of mpl for windows that has a bunch of extra diagnostic information turned on. This might help isolate which function is causing the problem. But if you can get a standalone script, that would be most efficient. Thanks, |
From: Robert L. <ro...@le...> - 2005-02-28 23:39:44
|
When attempting to generate a larger number of graph sets (i.e. 3 graphs of similar style over different data ranges), I'm intermittently getting a GPF on XP in na_backend_agg.pyd according to the report that M$ offers to send to itself. It is repeatable in one sense, in that if I restart the graph generation from the beginning it will fail at the same set, but if skip the first set of graphs it doesn't produce one additional set and then die, it dies at 15 (5 sets) earlier. I can restart from any of the sets where it failed and it will continue on for some random number before GPF'ing again - anything from 9 thru to 150 graphs or so. If I use Numeric (23.7, the latest) it is a lot worse - meaning fewer sets before failure. Also matplotlib 0.72 was a lot worse with either Numeric and numarray. The environment is Python 2.4, XP (sp2), matplotlib 0.72.1, numarray 1.2.2, Numeric 23.7 with the data coming from Postgres 8.0 via SQLObject and psycopg. I'm not sure of the best way to proceed from here - is this a known issue or related to one or should I attempt to produce a standalone test that causes the problem? Robert |
From: Axel K. <A.K...@gm...> - 2005-02-28 22:40:22
|
Hi, I'm using matplotlib 0.71 and I think I found a bug in polyfit. This simple linear regression on two data points gives the correct answer: >>> polyfit([731.924,731.988],[915,742],1) array([ -2703.12505517, 1979397.10294428]) However, if I multiply my x values by 1000 the result is wrong: >>> polyfit([731924,731988],[915,742],1) array([ 5.17650790e-009, 8.28496211e+002]) Could that be some kind of overflow problem ??? Alex |
From: Peter G. <pgr...@ge...> - 2005-02-28 20:34:19
|
John Hunter wrote: >>>>>>"Andrea" == Andrea Riciputi <ari...@pi...> writes: >>>>>> >>>>>> > > Andrea> Hi all, I'm an absolutely matplotlib newbie, so I'm sorry > Andrea> if my question is trivial. Anyway I've read the user guide > Andrea> and looked at the examples without finding out a solution. > > Andrea> Here it is my problem. Suppose I have a 2-dimensional > Andrea> array containg my data, and I want to produce a surface or > Andrea> a contour plot with it. Now the imshow() function seems > Andrea> the right way to go through. So far so good. Now suppose I > Andrea> want to draw the x,y axes for this plot, and suppose my > Andrea> axes are represented by **not-uniform** 1-dimensional > Andrea> array x[i], y[j]. How can I get the right ticks on the > Andrea> plot axes?? > >You need to interpolate your data onto a rectilinear grid and then use >pcolor. imshow requires that your data be an image -- eg the dx and >dy between rows and columns is the same between every row and column. >pcolor only assumes a rectilinear grid, so the dx and dy can vary from >row to row and column to column. But you have unstructured data. > >In matlab, the interpolation is handled by the griddata function. >Peter Groszkowski promised to post some code he uses to for this >purpose back in December, but apparently he got lost in the stars. > yup.. i did get a little "lost in the stars" - I forgot about it in fact. I promise I will post it in the next few days - this time I mean it. ;) -- Peter Groszkowski Gemini Observatory Tel: +1 808 9742509 670 N. A'ohoku Place Fax: +1 808 9359235 Hilo, Hawai'i 96720, USA |
From: Darren D. <dd...@co...> - 2005-02-28 18:50:50
|
Hi John, On Monday 28 February 2005 12:11 pm, John Hunter wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> oops, I just noticed a bug, the first script I posted wont > Darren> run. This updated script worked for me with a fresh 0.72.1 > Darren> installation. Sorry about the error. > > Hi Darren, this is very nice work. Sorry for the delay in getting > back but I've been tied up for the last week or so. Thanks. > > One comment I have is that I think we might choose the default offset > label differently. Visually > > 1e-5+12e-10 > 10 > 8 > 6 > 4 > 2 > > is hard to read because the two 10s line up when you should be > comparing the 12 with the 10. I wonder if this is better > > 1e-5+1e-10*12 > 10 > 8 > 6 > 4 > 2 > > Still an eyeful but at least the significant part of the ticks are > co-registered. What so you think? I originally did it the way you suggest, and changed it to make it more compact.... [...] > > Another comment is that these labels take up a lot of space, and will > pretty much break any default subplot which doesn't leave enough room > for them. > > Although I like the idea of using one of the tick labels > itself to handle the offset formatting, I wonder if we might be better > off using a special axis.set_offset command, so that for example, the > yaxis could place the offset above the ticks and thus take up less > horizontal space. Just a thought. Yeah, my intention this weekend was just to get the information into the plot, so it was clear what I was trying to accomplish. I would really like to get the scientific notation out of that last ticklabel, and put it above the axis as you suggest. Can we do proper exponential formatting, like with the logscale? I know there are scholarly journals out there that will complain about using the 'e' notation. > > Also, I'm inclined to make this the default formatter -- I am glad to hear that. > do you see > any problems with this? What troubles did you run into when you tried > to add these changes to the ScalarFormatter class and then rolled them > back because of clashes with derived classes? I originally hijacked ScalarFormatter, then noticed that the LogFormatter* classes inherited the pprint_val method from ScalarFormatter. That is really not a problem, we could just copy the old ScalarFormatter.pprint_val method to LogFormatter, then it will override the new ScalarFormatter method. Questions/problems before making this the default formatter: 1) Will the gui windows still report the appropriate coordinates? I noticed in the script I posted that the y coordinate was only reported as an integer. 2) in the script, near the bottom, try changing figure(2,figsize=(6,6)) ax1 = axes([.225,.74,.75,.2]) ax1.plot(arange(11)*1e-4) to read figure(2,figsize=(6,6)) ax1 = axes([.225,.74,.75,.2]) ax1.plot(arange(11)*1e-15) #<--- changed order of magnitude The resulting plot does not render the last ticklabel. I checked my script, and the string is generated by pprint_val, but it is not rendered. I dont understand why. Several orders of magnitude wont render. For example, 1e-107 doesnt render, nor does 1e-60, but 1e-61 does. I didnt see a problem with scientific notation containing positive exponents. Maybe this odd bug will not be reproducible once the information is rendered in its own space, I dont know. 3) (Almost not worth mentioning) I could run the same script 10 times and once it would yield an unsubscriptable object error message. When this happened, self.locs was set to None, and pprint_val was choking on this line: if x==self.locs[-1] and (self.orderOfMagnitude or self.offset): This problem will not exist when we stop rendering the offset/sci.not. in the ticklabel. I hesitate to even bring this nonexistent problem up, but if somebody notices this behavior, they should know it will not exist in the final product. -- Darren |
From: John H. <jdh...@ac...> - 2005-02-28 17:26:53
|
>>>>> "Massimo" == Massimo Sabbatini <sab...@de...> writes: Massimo> Dear group, is it possible to set the default sequence of Massimo> line styles, colors, widths, etc. to be used when Massimo> plotting multiple lines ? pylab.rc seems to set the Massimo> default parameters only for the first line. Massimo> I've googled about it, but it does not seem a very Massimo> popular question. No, this is not currently possible. The default line style does not cycle, and the default color cycle is hardcoded. It would be possible to make these configurable, but since it is relatively easy to specify which linestyles you want, I'm not sure it's necessary. JDH |
From: John H. <jdh...@ac...> - 2005-02-28 17:23:25
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> oops, I just noticed a bug, the first script I posted wont Darren> run. This updated script worked for me with a fresh 0.72.1 Darren> installation. Sorry about the error. Hi Darren, this is very nice work. Sorry for the delay in getting back but I've been tied up for the last week or so. One comment I have is that I think we might choose the default offset label differently. Visually 1e-5+12e-10 10 8 6 4 2 is hard to read because the two 10s line up when you should be comparing the 12 with the 10. I wonder if this is better 1e-5+1e-10*12 10 8 6 4 2 Still an eyeful but at least the significant part of the ticks are co-registered. What so you think? Likewise 10e-5 8 6 4 2 Becomes 1e-5*10 8 6 4 2 It takes more room but I find it easier to read because one naturally expects the significant digits to be in the same place. Another comment is that these labels take up a lot of space, and will pretty much break any default subplot which doesn't leave enough room for them. Although I like the idea of using one of the tick labels itself to handle the offset formatting, I wonder if we might be better off using a special axis.set_offset command, so that for example, the yaxis could place the offset above the ticks and thus take up less horizontal space. Just a thought. Also, I'm inclined to make this the default formatter -- do you see any problems with this? What troubles did you run into when you tried to add these changes to the ScalarFormatter class and then rolled them back because of clashes with derived classes? JDH |
From: John H. <jdh...@ac...> - 2005-02-28 16:46:29
|
>>>>> "oliver" == oliver tomic <oli...@ma...> writes: oliver> Hi folks, oliver> this might be a trivial question, but I could not figure oliver> it out from the documentation or the examples. oliver> I have a plot where the x-scale ranges from 0 to 20. When oliver> I plot a line it automatically starts at x=0. I would like oliver> the line to start at x=1. Is there a way to how I can do oliver> that? If I understand your question correctly, you want to set the xlim to range from 1-20 even if your data range from 0-20 >>> plot(x,y) >>> xlim(1,20) http://matplotlib.sf.net/matplotlib.pylab.html#-xlim http://matplotlib.sf.net/matplotlib.pylab.html#-axis JDH |
From: Massimo S. <sab...@de...> - 2005-02-28 16:07:43
|
Dear group, is it possible to set the default sequence of line styles, colors, widths, etc. to be used when plotting multiple lines ? pylab.rc seems to set the default parameters only for the first line. I've googled about it, but it does not seem a very popular question. Thank you in advance, Massimo |
From: matthew a. <ma...@ca...> - 2005-02-28 07:00:42
|
I went through the pygtk win32 setup thing again this month, and it's still a bit fiddly, but it's getting better. I updated the pygtk FAQ: http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq21.002.htp Alas ipython slows to a crawl using GTK interactively. It started happening sometime between gtk 2.2 and gtk 2.4. I'm still a bit dubious about gtk support for non-English win32. I've had some fatal problems with Japanese windows. The vibe I get from gtk developer lists about win32 is a bit negative. So I'm thinking of switching to wx on win32. It seems to work fine with ipython at least. m. On 12/02/2005 7:36 PM, Mark Hailes wrote: > Hi > > I think that GTK has some parallel development strands, which > is confusing ... |
From: Darren D. <dd...@co...> - 2005-02-28 01:40:50
|
oops, I just noticed a bug, the first script I posted wont run. This updated script worked for me with a fresh 0.72.1 installation. Sorry about the error. Darren from matplotlib import * rc('font',size='smaller') rc('tick',labelsize='smaller') from matplotlib.ticker import ScalarFormatter, LinearLocator import math from matplotlib.numerix import absolute, average from pylab import * class ScalarFormatterScientific(ScalarFormatter): """ Tick location is a plain old number. If useOffset==True and the data range <1e-4* the data average, then an offset will be determined such that the tick labels are meaningful. Scientific notation is used for data < 1e-4 or data >= 1e4. Scientific notation is presented once for each axis, in the last ticklabel. """ def __init__(self, useOffset=True): """ useOffset allows plotting small data ranges with large offsets: for example: [1+1e-9,1+2e-9,1+3e-9] """ self._useOffset = useOffset self.offset = 0 self.orderOfMagnitude = 0 self.format = None def set_locs(self, locs): self.locs = locs self._set_offset() self._set_orderOfMagnitude() self._set_format() def _set_offset(self): # offset of 20,001 is 20,000, for example if self._useOffset: ave_loc = average(self.locs) std_loc = std(self.locs) if ave_loc: # dont want to take log10(0) ave_oom = math.floor(math.log10(absolute(ave_loc))) if std_loc/math.fabs(ave_loc) < 1e-4: # four sig-figs # add 1e-15 because of floating point precision, fixes conversion self.offset = int(ave_loc/10**ave_oom+1e-15)*10**ave_oom else: self.offset = 0 def _set_orderOfMagnitude(self): # if scientific notation is to be used, find the appropriate exponent # if using an offset, find the OOM after applying the offset locs = array(self.locs)-self.offset ave_loc_abs = average(absolute(locs)) oom = math.floor(math.log10(ave_loc_abs)) # need to special-case for range of 0-1e-5 if oom <= 0 and std(locs) < 1e-4:#10**(2*oom): self.orderOfMagnitude = oom elif oom <=0 and oom >= -5: pass elif math.fabs(oom) >= 4: self.orderOfMagnitude = oom def _set_format(self): # set the format string to format all the ticklabels locs = (array(self.locs,'d')-self.offset) / \ 10**self.orderOfMagnitude+1e-15 sigfigs = [len(str('%1.4f'% loc).split('.')[1].rstrip('0')) \ for loc in locs] sigfigs.sort() self.format = '%1.' + str(sigfigs[-1]) + 'f' def pprint_val(self, x, d): # d is no longer necessary, x is the tick location. xp = (x-self.offset)/10**self.orderOfMagnitude if x==self.locs[-1] and (self.orderOfMagnitude or self.offset): offsetStr = '' sciNotStr = '' xp = self.format % xp if self.offset: p = '%1.e+'% self.offset offsetStr = self._formatSciNotation(p) if self.orderOfMagnitude: p = 'x%1.e'% 10**self.orderOfMagnitude sciNotStr = self._formatSciNotation(p) return ''.join((offsetStr,xp,sciNotStr[2:])) elif xp==0: return '%d'% xp else: return self.format % xp def _formatSciNotation(self,s): # transform 1e+004 into 1e4, for example tup = s.split('e') mantissa = tup[0] sign = tup[1][0].replace('+', '') exponent = tup[1][1:].lstrip('0') return '%se%s%s' %(mantissa, sign, exponent) figure(1,figsize=(6,6)) ax1 = axes([.2,.74,.75,.2]) ax1.plot(arange(11)*5e2) ax1.yaxis.set_major_formatter(ScalarFormatterScientific()) ax1.xaxis.set_visible(False) ax1.set_title('BIG NUMBERS',fontsize=14) ax2 = axes([.2,.51,.75,.2]) ax2.plot(arange(11)*1e4) ax2.yaxis.set_major_formatter(ScalarFormatterScientific()) ax2.text(1,6e4,'y=1e4*x') ax2.xaxis.set_visible(False) ax3 = axes([.2,.28,.75,.2]) ax3.plot(arange(11)*1e4+1e10) ax3.yaxis.set_major_formatter(ScalarFormatterScientific()) ax3.text(1,6e4+1e10,'y=1e4*x+1e10') ax3.xaxis.set_visible(False) ax4 = axes([.2,.05,.75,.2]) ax4.plot(arange(11)*1e4+1e10) ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False)) ax4.text(1,1e10+6e4,'y=1e4*x+1e10, no offset') figure(2,figsize=(6,6)) ax1 = axes([.225,.74,.75,.2]) ax1.plot(arange(11)*1e-4) ax1.yaxis.set_major_formatter(ScalarFormatterScientific()) ax1.xaxis.set_visible(False) ax1.set_title('small numbers',fontsize=8) ax2 = axes([.225,.51,.75,.2]) ax2.plot(arange(11)*1e-5) ax2.yaxis.set_major_formatter(ScalarFormatterScientific()) ax2.text(1,6e-5,'y=1e-5*x') ax2.xaxis.set_visible(False) ax3 = axes([.225,.28,.75,.2]) ax3.plot(arange(11)*1e-10+1e-5) ax3.yaxis.set_major_formatter(ScalarFormatterScientific()) ax3.text(1,1e-5+6e-10,'y=1e-10*x+1e-5') ax3.xaxis.set_visible(False) ax4 = axes([.225,.05,.75,.2]) ax4.plot(arange(11)*1e-10+1e-5) ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False)) ax4.text(1,1e-5+6e-10,'y=1e-10*x+1e-5, no offset') show() |
From: Brian R. <br...@se...> - 2005-02-28 00:16:23
|
Hi, I am a new matplotlib (and new to this list) interested in use for digital printing. I made a post in response to a recent presentation on matplotlib in Chicago: http://brianray.chipy.org/Python/matplotlib.html BTW, thanks to John Hunter for the ground breaking presentation at http://chipy.org. You and anyone on this list is invited to come to our future meetings. Thanks! Brian Ray - Chicago IL 773 835 9876 http://brianray.chipy.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
From: Robert L. <ro...@le...> - 2005-02-27 23:17:12
|
Alex Rada wrote: > Hi, > > I'm new to pylab, and I find it very usefull. I want to know how is > possibile to change font properties in legend (I particular fontsize): I > tried adding "prop = FontProperties("smaller")" in legend(), but this > give me an error... maybe I'm wrong... > Try: prop = FontProperties( size="smaller" ) From font_manager.py: size - Either an absolute value of xx-small, x-small, small, medium, large, x-large, xx-large; or a relative value of smaller or larger; or an absolute font size, e.g. 12; or scalable. Robert |
From: Alex R. <ale...@gm...> - 2005-02-27 22:54:30
|
Hi, I'm new to pylab, and I find it very usefull. I want to know how is possibile to change font properties in legend (I particular fontsize): I tried adding "prop = FontProperties("smaller")" in legend(), but this give me an error... maybe I'm wrong... Thanks, Alex. |
From: Darren D. <dd...@co...> - 2005-02-27 18:43:35
|
I need to plot some arrays that may begin or end with nan's. Currently, mpl does a good job handling something like plot([1,2,nan,4]), but the has trouble with plot([nan,2,3,4]) and plot([1,2,3,nan]). Could somebody point me in the right direction: where can I look in the sourcecode to learn how mpl deals with plotting nans? -- Darren |
From: Darren D. <dd...@co...> - 2005-02-26 20:12:42
|
On Friday 25 February 2005 08:45 am, Darren Dale wrote: > On Thursday 24 February 2005 11:02 pm, John Hunter wrote: > > >>>>> "Hans" == Hans Fangohr <H.F...@so...> writes: > > > > Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show() > > > > Hans> All works fine when I subtract the mean of x but there seems > > Hans> to be a problem with labelling axes for plotted data which > > Hans> is not close to zero but shows only small variations. > > > > I agree it's a bug. It's not immediately clear to me what the labels > > should be though > > > > 1.0000000002 > > 1.0000000004 > > 1.0000000006 > > > > and so on? That takes up a lot of room. Granted, correct but ugly > > is better than incorrect but pretty, but I'm curious if there is a > > better way to format these cases. Perhaps ideal would be an indicator > > at the bottom or top of the y axis that read '1+' and then use 2e-9, > > 4e-9, etc as the actual tick labels. Do you agree this is ideal? I worked on a new formatter yesterday and today. It includes the indicator that John described above, right now in the last ticklabel at the top of the axis. This custom formatter also includes scientific notation in the last ticklabel only. The ultimate goal is to have scientific notation be formatted like in the logplots, but I havent gotten that far yet. Using the offset makes a large ticklabel at the moment. You can pass useOffset=False to ScalarFormatterScientific to turn this feature off (see end of script below). Interested parties, please give this script a whirl and send me your comments. (John, I have now subclassed ScalarFormatter, I didnt realize I had altered a method that other formatters were inheriting.) Darren from matplotlib import * rc('font',size='smaller') rc('tick',labelsize='smaller') from matplotlib.ticker import ScalarFormatter, LinearLocator import math from matplotlib.numerix import absolute, average from pylab import * class ScalarFormatterScientific(ScalarFormatter): """ Tick location is a plain old number. If viewInterval is set, the formatter will use %d, %1.#f or %1.ef as appropriate. If it is not set, the formatter will do str conversion """ def __init__(self, useOffset=True): """ useOffset allows plotting small data ranges with large offsets: for example: [1+1e-9,1+2e-9,1+3e-9] """ self._useOffset = useOffset def set_locs(self, locs): self.locs = locs self._set_offset() self._set_orderOfMagnitude() self._set_format() def _set_offset(self): # offset of 20,001 is 20,000, for example if self._useOffset: ave_loc = average(self.locs) std_loc = std(self.locs) if ave_loc: # dont want to take log10(0) ave_oom = math.floor(math.log10(absolute(ave_loc))) if std_loc/math.fabs(ave_loc) < 1e-4: # four sig-figs # add 1e-15 because of floating point precision, fixes conversion self.offset = int(ave_loc/10**ave_oom+1e-15)*10**ave_oom else: self.offset = 0 def _set_orderOfMagnitude(self): # if using an offset, oom applies after applying the offset locs = array(self.locs)-self.offset ave_loc_abs = average(absolute(locs)) oom = math.floor(math.log10(ave_loc_abs)) # need to special-case for range of 0-1e-5 if oom <= 0 and std(locs) < 1e-4:#10**(2*oom): self.orderOfMagnitude = oom elif oom <=0 and oom >= -5: pass elif math.fabs(oom) >= 4: self.orderOfMagnitude = oom def _set_format(self): locs = (array(self.locs,'d')-self.offset) / \ 10**self.orderOfMagnitude+1e-15 sigfigs = [len(str('%1.4f'% loc).split('.')[1].rstrip('0')) \ for loc in locs] sigfigs.sort() self.format = '%1.' + str(sigfigs[-1]) + 'f' def pprint_val(self, x, d): xp = (x-self.offset)/10**self.orderOfMagnitude if x==self.locs[-1] and (self.orderOfMagnitude or self.offset): offsetStr = '' sciNotStr = '' xp = self.format % xp if self.offset: p = '%1.e+'% self.offset offsetStr = self._formatSciNotation(p) if self.orderOfMagnitude: p = 'x%1.e'% 10**self.orderOfMagnitude sciNotStr = self._formatSciNotation(p) return ''.join((offsetStr,xp,sciNotStr)) elif xp==0: return '%d'% xp else: return self.format % xp def _formatSciNotation(self,s): tup = s.split('e') mantissa = tup[0] sign = tup[1][0].replace('+', '') exponent = tup[1][1:].lstrip('0') return '%se%s%s' %(mantissa, sign, exponent) figure(1,figsize=(6,6)) ax1 = axes([.2,.74,.75,.2]) ax1.plot(arange(11)*5e2) ax1.yaxis.set_major_formatter(ScalarFormatterScientific()) ax1.xaxis.set_visible(False) ax1.set_title('BIG NUMBERS',fontsize=14) ax2 = axes([.2,.51,.75,.2]) ax2.plot(arange(11)*1e4) ax2.yaxis.set_major_formatter(ScalarFormatterScientific()) ax2.text(1,6e4,'6e4') ax2.xaxis.set_visible(False) ax3 = axes([.2,.28,.75,.2]) ax3.plot(arange(11)*1e4+1e10) ax3.yaxis.set_major_formatter(ScalarFormatterScientific()) ax3.text(1,6e4+1e10,'1e10+6e4') ax3.xaxis.set_visible(False) ax4 = axes([.2,.05,.75,.2]) ax4.plot(arange(11)*1e4+1e10) ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False)) ax4.text(1,1e10+6e4,'same as above, no offset') figure(2,figsize=(6,6)) ax1 = axes([.225,.74,.75,.2]) ax1.plot(arange(11)*5e-5) ax1.yaxis.set_major_formatter(ScalarFormatterScientific()) ax1.xaxis.set_visible(False) ax1.set_title('small numbers',fontsize=8) ax2 = axes([.225,.51,.75,.2]) ax2.plot(arange(11)*1e-5) ax2.yaxis.set_major_formatter(ScalarFormatterScientific()) ax2.text(1,6e-5,'6e-5') ax2.xaxis.set_visible(False) ax3 = axes([.225,.28,.75,.2]) ax3.plot(arange(11)*1e-10+1e-5) ax3.yaxis.set_major_formatter(ScalarFormatterScientific()) ax3.text(1,1e-5+6e-10,'6e-10+1e-5') ax3.xaxis.set_visible(False) ax4 = axes([.225,.05,.75,.2]) ax4.plot(arange(11)*1e-10+1e-5) ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False)) ax4.text(1,1e-5+6e-10,'same as above, no offset') show() |
From: Humufr <hu...@ya...> - 2005-02-25 21:40:41
|
Hi, I see a problem when I'm using autoscale. I have a spectra with huge difference in y. I used xlim to look only a part of my spectra and the ylim is not autoscale to this peculiar part of the spectra but on all the spectra. I'm using the last CVS version. Thanks, N. |
From: Humufr <hu...@ya...> - 2005-02-25 21:36:32
|
Hi, I found something strange inside the eps file create with matplotlib. I used matplotlib to trace a port of a spectra (I used the function plot and axis). I have been very surprise to see that all the spectra was inside the eps file. To see it, I must admit that I did something weird. I create an eps file with matplotlib and I transform the file in svg format with pstoedit and I edit this file with inkscape. I don't know where is the problem but I don't think that it's necessary to have all the point inside the output file, perhaps it's not possible to do anything to change it but that can create some huge file. So if nothing can be done, that will be a good idea to put it in the FAQ to let the users cut their data if needed. N. |
From: Perry G. <pe...@st...> - 2005-02-25 19:57:45
|
On Feb 25, 2005, at 12:40 PM, John Hunter wrote: >>>>>> "Andrea" == Andrea Riciputi <ari...@pi...> writes: > > Andrea> Hi all, I'm an absolutely matplotlib newbie, so I'm sorry > Andrea> if my question is trivial. Anyway I've read the user guide > Andrea> and looked at the examples without finding out a solution. > > Andrea> Here it is my problem. Suppose I have a 2-dimensional > Andrea> array containg my data, and I want to produce a surface or > Andrea> a contour plot with it. Now the imshow() function seems > Andrea> the right way to go through. So far so good. Now suppose I > Andrea> want to draw the x,y axes for this plot, and suppose my > Andrea> axes are represented by **not-uniform** 1-dimensional > Andrea> array x[i], y[j]. How can I get the right ticks on the > Andrea> plot axes?? > > You need to interpolate your data onto a rectilinear grid and then use > pcolor. imshow requires that your data be an image -- eg the dx and > dy between rows and columns is the same between every row and column. > pcolor only assumes a rectilinear grid, so the dx and dy can vary from > row to row and column to column. But you have unstructured data. > I'm not sure if that is what is being said. What may be referred to is a structured 2-d image for which it is intended that the data coordinates be taken from the x and y arrays (for corresponding locations). The contour task does allow one to give such x and y arrays, but not the image display tasks (if I remember correctly). Some clarification is needed. Perry |
From: Eric F. <ef...@ha...> - 2005-02-25 18:57:23
|
John, > Eric> Having solved that problem, I am getting more optimistic > Eric> about being able to come up with a usable filled contour > Eric> capability fairly quickly. Still no promises, though. > > Great -- be mindful of the contourf matlab docstrings. Strict > adherence is not required, but it is nice to be compatible where > possible. I have the basic filled contour functionality working, with the following caveats, comments, and questions: 0) I've done only the simplest of testing so far. 1) There is a fundamental difference in strategy between Matlab's contour patch generation algorithm and gcntr.c: Matlab makes all patches as simply connected regions without branch cuts, but gcntr polygons have branch cuts. This means that we can't use the polygon edges; if one wants line contours at the contour levels, they must be drawn separately, by asking gcntr for lines, as contour does. My inclination is to leave it this way: the user can simply call contourf to get the filled regions, and then call contour to add lines as needed. Typically I draw lines at only a few of the color boundaries, and sometimes I draw additional lines within colored regions, so this is the way I normally use matlab contourf and contour anyway. 2) In the present version, there is much too much duplication of code between contour and contourf in axes.py; I copied the contour function to contourf, modified what I needed to, and moved only the ContourMappable class out to the module level. I would like to factor out more of the common code. 3) The docstrings in axes.py are driving me nuts--lacking proper indentation, they make it very difficult to find the function definitions. I presume this is because of the way boilerplate.py is generating the pylab.py functions and their docstrings. I haven't looked at boilerplate.py (I haven't used it yet at all), but I suspect it would be easy to change things so that it would handle properly indented docstrings. Is it OK if I do this? 4) ToDo: it is not standard in matlab, but for filled contouring I always use a matching colorbar--essentially a colorbar contoured with the same levels and colors as the contour plot itself, rather than one that shows the whole colormap. 5) ToDo: I haven't tried to do anything with region masking yet; maybe I will get to it soon, since it is something I need. 5) gcntr.c uses global variables, which presumably means that it will fail if called from more than one thread at a time. Longer term, should I/we/someone modify it so that this not the case? Or is this characteristic of other routines used by matplotlib, so there is no point in worrying about gcntr.c in particular? 6) When the time comes to send you my modifications, how should I do it: diffs, or complete files? Send to you directly, or to the list? If you would prefer diffs, please give me an example of the exact diff command options to use. (I am working with matplotlib-0.72.1 as a starting point.) Modified files will include axes.py, pylab.py (and/or boilerplate.py), _contour.c, and an example. Eric |
From: John H. <jdh...@ac...> - 2005-02-25 17:52:25
|
>>>>> "Andrea" == Andrea Riciputi <ari...@pi...> writes: Andrea> Hi all, I'm an absolutely matplotlib newbie, so I'm sorry Andrea> if my question is trivial. Anyway I've read the user guide Andrea> and looked at the examples without finding out a solution. Andrea> Here it is my problem. Suppose I have a 2-dimensional Andrea> array containg my data, and I want to produce a surface or Andrea> a contour plot with it. Now the imshow() function seems Andrea> the right way to go through. So far so good. Now suppose I Andrea> want to draw the x,y axes for this plot, and suppose my Andrea> axes are represented by **not-uniform** 1-dimensional Andrea> array x[i], y[j]. How can I get the right ticks on the Andrea> plot axes?? You need to interpolate your data onto a rectilinear grid and then use pcolor. imshow requires that your data be an image -- eg the dx and dy between rows and columns is the same between every row and column. pcolor only assumes a rectilinear grid, so the dx and dy can vary from row to row and column to column. But you have unstructured data. In matlab, the interpolation is handled by the griddata function. Peter Groszkowski promised to post some code he uses to for this purpose back in December, but apparently he got lost in the stars. matlab uses a delaunay triangulation according to the documentation for griddata -- I think Peter uses a different approach. I looked at the scipy interpolate module but didn't see anything that looked just right -- perhaps I missed it. It surprises that scipy doesn't have a delaunay triangulation routine, but apparently it does not. A quick google for revealed http://www.python.org/pypi?:action=display&name=Delny&version=0.1.0a2 which relies on the gnu qhull library... A griddata function for mpl would be a nice complement to the meshgrid function. JDH |
From: Darren D. <dd...@co...> - 2005-02-25 17:05:48
|
On Friday 25 February 2005 11:33 am, John Hunter wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> Hi, I am trying to install from cvs, but am getting error > Darren> messages that the numerix module is missing. It is not > Darren> listed on the "browse cvs repository" page at sourceforge > Darren> either. > > Try getting a new CVS checkout in a clean directory and rm -rf > site-packages/matplotlib before rebuilding. The numerix module does > exist in CVS: > > > http://cvs.sourceforge.net/viewcvs.py/matplotlib/matplotlib/lib/matplotlib/ >numerix/ > > The numerix code was reorganized in 0.71 so if you are using an older > version that can cause problems. The first line of defense when > confronting a matplotlib bug is > > > sudo rm -rf build /usr/local/lib/python2.3/site-packages/matplotib > > sudo python setup.py install > > distutils keeps old code around in the build directory. If for > example you have somemod.so from an older mpl version, and then we > refactor to use somemod.py which conditionally imports _na_somemod.so > or _nc_somemod.so depending on your numerix setting, the old > somemod.so will be installed from your build dir into site-packages > alongside somemod.py but the old *.so will be imported rather than the > new *.py. This has caused us lots of problems - I don't think a > 'python setup.py clean' will solve every problem, but flushing the > build directory and site-packages/matplotlib before a new install has > cured lots of bugs. > > Or else sourceforge CVS is whacked, which would not bee too > surprising. > My mistake. I thought I had cleared the build and site-packages/mpl directory, but I guess I overlooked something. I did a new cvs co and numerix is back. Thanks. -- Darren |
From: John H. <jdh...@ac...> - 2005-02-25 16:45:43
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> Hi, I am trying to install from cvs, but am getting error Darren> messages that the numerix module is missing. It is not Darren> listed on the "browse cvs repository" page at sourceforge Darren> either. Try getting a new CVS checkout in a clean directory and rm -rf site-packages/matplotlib before rebuilding. The numerix module does exist in CVS: http://cvs.sourceforge.net/viewcvs.py/matplotlib/matplotlib/lib/matplotlib/numerix/ The numerix code was reorganized in 0.71 so if you are using an older version that can cause problems. The first line of defense when confronting a matplotlib bug is > sudo rm -rf build /usr/local/lib/python2.3/site-packages/matplotib > sudo python setup.py install distutils keeps old code around in the build directory. If for example you have somemod.so from an older mpl version, and then we refactor to use somemod.py which conditionally imports _na_somemod.so or _nc_somemod.so depending on your numerix setting, the old somemod.so will be installed from your build dir into site-packages alongside somemod.py but the old *.so will be imported rather than the new *.py. This has caused us lots of problems - I don't think a 'python setup.py clean' will solve every problem, but flushing the build directory and site-packages/matplotlib before a new install has cured lots of bugs. Or else sourceforge CVS is whacked, which would not bee too surprising. JDH |
From: Darren D. <dd...@co...> - 2005-02-25 16:27:38
|
Hi, I am trying to install from cvs, but am getting error messages that the numerix module is missing. It is not listed on the "browse cvs repository" page at sourceforge either. -- Darren |
From: Matt N. <new...@ca...> - 2005-02-25 16:11:58
|
> > I agree it's a bug. It's not immediately clear to me what the labels > > should be though > > > > 1.0000000002 > > 1.0000000004 > > 1.0000000006 > > > > and so on? That takes up a lot of room. Granted, correct but ugly > > is better than incorrect but pretty, but I'm curious if there is a > > better way to format these cases. Perhaps ideal would be an indicator > > at the bottom or top of the y axis that read '1+' and then use 2e-9, > > 4e-9, etc as the actual tick labels. Do you agree this is ideal? More likely, the plot should be of 1-x, not x, with 1 subtracted from the data before being sent to the plot. Would you use seconds-since-1970 to make a plot versus Time with a range of 1 sec and data every millisecond? The data plotted should be the "significant digits" after all. FWIW, a custom tick formatter I've been using is below. It's a slight variation on the default, and won't solve the space needed to display "1 + n*1.e-9", but it will do a reasonable job of picking the number of significant digits to show based on the data range for the Axis. It could be expanded.... --Matt ! def myformatter(self, x=1.0, axis=None): ! """ custom tick formatter to use with FuncFormatter(): ! x value to be formatted ! axis Axis instance to use for formatting ! """ ! fmt = '%1.5g' ! if axis == None: ! return fmt % x ! ! # attempt to get axis span (range of values to format) ! delta = 0.2 ! try: ! ticks = axis.get_major_locator()() ! delta = abs(ticks[1] - ticks[0]) ! except: ! try: ! delta = 0.1 * axis.get_view_interval().span() ! except: ! pass ! ! if delta > 99999: fmt = '%1.6e' ! elif delta > 0.99: fmt = '%1.0f' ! elif delta > 0.099: fmt = '%1.1f' ! elif delta > 0.0099: fmt = '%1.2f' ! elif delta > 0.00099: fmt = '%1.3f' ! elif delta > 0.000099: fmt = '%1.4f' ! elif delta > 0.0000099: fmt = '%1.5f' ! ! s = fmt % x ! s.strip() ! s = s.replace('+', '') ! while s.find('e0')>0: s = s.replace('e0','e') ! while s.find('-0')>0: s = s.replace('-0','-') ! ! return s |