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
(36) |
2
(10) |
3
(8) |
4
|
5
(4) |
6
(15) |
7
(17) |
8
(3) |
9
(8) |
10
(5) |
11
(2) |
12
(5) |
13
(5) |
14
(15) |
15
(3) |
16
(10) |
17
(6) |
18
(2) |
19
(1) |
20
(11) |
21
(33) |
22
(13) |
23
(14) |
24
(15) |
25
(4) |
26
(5) |
27
(9) |
28
(12) |
29
(7) |
30
(8) |
31
(6) |
|
Anthony M. Floyd wrote: >> -----Original Message----- >> From: Eric Firing [mailto:ef...@ha...] > > [snip] > >> It probably comes down to program simplicity and readability, >> not speed, in your case. >> >> Eric > > > Hi Eric, > > Thanks for this. That's essentially the decision I had reached, but I > was also wondering if I'd missed something significant. I think I will > code it up as-is right now, and if the routine is unacceptably slow > re-examine it with an eye to shifting over to using line-collections. > > In the same vein, if I need to refactor, is there any benefit to > treating single series as a collection with only one segment? I would > rather treat single series and multiple series in the same manner -- > either plotting single series and multiple single-series or plotting > single-series collections and multiple-series collections. That is, I'd > rather not have to treat plotting a single series in one manner and > multiple series in another. A collection with only one member should work fine, although I don't know whether it has been explicitly tested. So, I don't see any reason why you should have to treat a single series as a special case. Are you aware that the plot method can plot the columns of 2-D arrays? Any kwargs apply to all the lines. When plot does this, it makes a list of lines, not a line collection, so it is similar to looping over a set of single plot commands. There is no particular speed advantage, but it is nice and concise, if it yields what you actually want. Eric > > Thanks, > Anthony. > >
> -----Original Message----- > From: Eric Firing [mailto:ef...@ha...]=20 [snip] > It probably comes down to program simplicity and readability,=20 > not speed, in your case. >=20 > Eric Hi Eric, Thanks for this. That's essentially the decision I had reached, but I was also wondering if I'd missed something significant. I think I will code it up as-is right now, and if the routine is unacceptably slow re-examine it with an eye to shifting over to using line-collections. In the same vein, if I need to refactor, is there any benefit to treating single series as a collection with only one segment? I would rather treat single series and multiple series in the same manner -- either plotting single series and multiple single-series or plotting single-series collections and multiple-series collections. That is, I'd rather not have to treat plotting a single series in one manner and multiple series in another. Thanks, Anthony.=20
Anthony, When I do a quick test of line_collection.py versus a modification that makes individual plot calls, with the results written to a png file, I get about 1.05 s with the collection and 1.2 s with the lines. But a trivial plot still takes 0.52 seconds, so if you subtract out this general startup overhead the improvement with the line collection is about 30%. It probably comes down to program simplicity and readability, not speed, in your case. Eric Anthony M. Floyd wrote: > I'm trying to figure out the best way to handle the following situation: > I have a wxApp that embeds a matplotlib figure in a panel. I use custom > code to control adding and removing series from the axes in this figure, > with some pretty fine grained control on when things get drawn, zoomed, > etc. To be clear, I'm not using pylab here, I'm coding directly into > matplotlib. > > Anyhow, I now have the case where I want to be plotting a modest number > of series (say 100) with a reasonably large density (say >1000 pts). > These series will all have the same or similar styles (thickness, > colour, etc) and will definitely have the same length. > > In context of my current app, I could achieve this simply by calling my > .addSeries routine multiple times. Or, I could use a Line Collection to > handle them en masse. > > The thing is, after taking a quick read through of the source code, I'm > not certain that I'm gaining anything by using a line collection in this > case. > > I did a quick comparison using the line_collection.py example, and even > using pylab there didn't seem to be any performance hit to doing: > > lines = [zip(x,y) for y in ys] > for series in x: > plot(lines[series]) > > Instead of using: > > line_segments = ... > ax.add_collection(line_segments) > > Can anyone give me advice if I should code targeting collections or to > just use my current single-series code? > > Thanks, > Anthony. > > > > -- > Anthony Floyd, PhD > Convergent Manufacturing Technologies Inc. > 6190 Agronomy Rd, Suite 403 > Vancouver BC V6T 1Z3 > CANADA > > Email: Ant...@co... | Tel: 604-822-9682 > WWW: http://www.convergent.ca | Fax: 604-822-9659 > > CMT is hiring: See http://www.convergent.ca for details > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
I'm trying to figure out the best way to handle the following situation: I have a wxApp that embeds a matplotlib figure in a panel. I use custom code to control adding and removing series from the axes in this figure, with some pretty fine grained control on when things get drawn, zoomed, etc. To be clear, I'm not using pylab here, I'm coding directly into matplotlib. Anyhow, I now have the case where I want to be plotting a modest number of series (say 100) with a reasonably large density (say >1000 pts). These series will all have the same or similar styles (thickness, colour, etc) and will definitely have the same length. In context of my current app, I could achieve this simply by calling my .addSeries routine multiple times. Or, I could use a Line Collection to handle them en masse. The thing is, after taking a quick read through of the source code, I'm not certain that I'm gaining anything by using a line collection in this case. =20 I did a quick comparison using the line_collection.py example, and even using pylab there didn't seem to be any performance hit to doing: lines =3D [zip(x,y) for y in ys] for series in x: plot(lines[series]) Instead of using: line_segments =3D ... ax.add_collection(line_segments) Can anyone give me advice if I should code targeting collections or to just use my current single-series code? Thanks, Anthony. -- Anthony Floyd, PhD Convergent Manufacturing Technologies Inc. 6190 Agronomy Rd, Suite 403 Vancouver BC V6T 1Z3 CANADA Email: Ant...@co... | Tel: 604-822-9682 WWW: http://www.convergent.ca | Fax: 604-822-9659 =20 CMT is hiring: See http://www.convergent.ca for details
That did it. thanks! Eric Firing wrote: > Johann Cohen-Tanugi wrote: >> hello, >> I am using matplotlib to make a drawing, so though I am using >> distances on the pad I do not need to display the axes and would >> rather have no frame and no tick. >> To achieve this, I tried using : >> rc('axes', edgecolor='white') > > If your axes instance is "ax", try > ax.set_frame_on(False) > ax.set_axis_off() > > The api is inconsistent, but there it is... > > This will actually wipe out the axes patch as well as the boundary, > and all traces of the axes; maybe this is more than you want. > > Eric > >> rc('xtick', color='white') >> rc('ytick', color='white') >> >> The first command works, but not the 2 tick commands (the ticks still >> show up, in black)...... Bug or feature? Besides, I am sure there is >> a better way to do that, but could not find out. >> I am using the GTKAgg backend. >> >> thanks, >> Johann >> >> >> ------------------------------------------------------------------------- >> >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >
Johann Cohen-Tanugi wrote: > hello, > I am using matplotlib to make a drawing, so though I am using distances > on the pad I do not need to display the axes and would rather have no > frame and no tick. > To achieve this, I tried using : > rc('axes', edgecolor='white') If your axes instance is "ax", try ax.set_frame_on(False) ax.set_axis_off() The api is inconsistent, but there it is... This will actually wipe out the axes patch as well as the boundary, and all traces of the axes; maybe this is more than you want. Eric > rc('xtick', color='white') > rc('ytick', color='white') > > The first command works, but not the 2 tick commands (the ticks still > show up, in black)...... Bug or feature? Besides, I am sure there is a > better way to do that, but could not find out. > I am using the GTKAgg backend. > > thanks, > Johann > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
On 20/08/07, Darren Dale <dd...@co...> wrote: > On Monday 20 August 2007 12:11:30 pm Samuel M.Smith wrote: > > I can only generate .eps files that will successfully distill > > into .pdf files when I use > > > > ps.usedistiller : xpdf > > not > > ps.usedistiller : ghostscript > > nor > > ps.usedistiller : None > > > > Is this a known problem? > > ghostscript does work fine for .ps files just not .eps > > No, it is not a known problem. I have never had a problem converting an eps to > pdf, using either setting. Are you using epstopdf? Could you post an example, > something that actually illustrates a problem? > > > In addition when ever I save a .eps file I get the following error > > even though it creates the file ok > > > > : Error: No paper information available - using defaults > > > > %%BoundingBox: 78 220 543 561 > > %%HiResBoundingBox: 78.281998 220.589993 542.375983 560.357983 > > > > Is there a way to fix this? > > Is this with verbose.level set to silent? Interestingly I just installed ubuntu gutsy AMD64 on my machine (yes I know it's alpha) and found that I get a strangely similar problem (with subversion matplotlib). But only if i use *xpdf* as the distiller, not ghostscript. I also get the same error with the bounding box / no paper information. I put it down to ubuntu alpha status rather than matplotlib which is why I didn't report it, but this has made me think possibly otherwise?? I'll send more details if you're interested. John
On 2007年8月20日, Johann Cohen-Tanugi apparently wrote: > I am sure there is a > better way to do that Set the ticks to an empty tuple. hth, Alan Isaac
hello, I am using matplotlib to make a drawing, so though I am using distances on the pad I do not need to display the axes and would rather have no frame and no tick. To achieve this, I tried using : rc('axes', edgecolor='white') rc('xtick', color='white') rc('ytick', color='white') The first command works, but not the 2 tick commands (the ticks still show up, in black)...... Bug or feature? Besides, I am sure there is a better way to do that, but could not find out. I am using the GTKAgg backend. thanks, Johann
On Monday 20 August 2007 12:11:30 pm Samuel M.Smith wrote: > I can only generate .eps files that will successfully distill > into .pdf files when I use > > ps.usedistiller : xpdf > not > ps.usedistiller : ghostscript > nor > ps.usedistiller : None > > Is this a known problem? > ghostscript does work fine for .ps files just not .eps No, it is not a known problem. I have never had a problem converting an eps to pdf, using either setting. Are you using epstopdf? Could you post an example, something that actually illustrates a problem? > In addition when ever I save a .eps file I get the following error > even though it creates the file ok > > : Error: No paper information available - using defaults > > %%BoundingBox: 78 220 543 561 > %%HiResBoundingBox: 78.281998 220.589993 542.375983 560.357983 > > Is there a way to fix this? Is this with verbose.level set to silent?
I can only generate .eps files that will successfully distill into .pdf files when I use ps.usedistiller : xpdf not ps.usedistiller : ghostscript nor ps.usedistiller : None Is this a known problem? ghostscript does work fine for .ps files just not .eps In addition when ever I save a .eps file I get the following error even though it creates the file ok : Error: No paper information available - using defaults %%BoundingBox: 78 220 543 561 %%HiResBoundingBox: 78.281998 220.589993 542.375983 560.357983 Is there a way to fix this? I have ps.papersize : letter my configuration Mac OS X 10.4.10 PPC python 2.5.1 Matplotlib 0.90.1 ipython 0.8.1 wxPython2.8-osx-unicode-2.8.3.0-universal10.4-py2.5 ghostscript 8.54 xpdf 3.02 ********************************************************************** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84005-4108 801-768-2768 voice 801-768-2769 fax ********************************************************************** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" **********************************************************************