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
|
2
|
3
(3) |
4
(6) |
5
(5) |
6
(5) |
7
|
8
|
9
(1) |
10
(5) |
11
(11) |
12
(6) |
13
(6) |
14
(4) |
15
(1) |
16
(1) |
17
(10) |
18
(20) |
19
(5) |
20
(7) |
21
(1) |
22
|
23
|
24
|
25
(1) |
26
(3) |
27
(1) |
28
|
29
(1) |
30
(2) |
31
(3) |
|
|
|
|
|
On Wed, Dec 12, 2012 at 7:55 AM, Forrester, Kurt < kur...@gm...> wrote: > ax.set_xlim(0.5, 2) > ax.set_xscale('log', basex=2, subsx=range(2,9)) > Kurt, That `subsx` kwarg is tricky. Does this example get you closer to what you want? import numpy as np import matplotlib.pyplot as plt fig, ax = plt.subplots() ax.set_xlim(0.5, 10) ax.set_xscale('log', basex=2, subsx=np.arange(1.,2.1,0.1)) ax.xaxis.grid(True, which='minor') plt.show() -paul
I cannot seem to get the following code produce what I expect. I want minor tick marks between my major ticks on a base 2 logx plot. ax = axes() ax.set_xlim(0.5, 2) ax.set_xscale('log', basex=2, subsx=range(2,9)) grid(b=True, which='minor') I would have expected there to be minor ticks at 2^(-1:0.1:1) excluding -1,0 and 1. Any help would be appreciated. Kind regards, Kurt
Hi everyone, Just FYI, IPython just received 1ドル.15 million in funding from the Alfred P. Sloan Foundation to support development over the next 2 years. Fernando talks more about this in his post to the IPython mailing list: http://mail.scipy.org/pipermail/ipython-dev/2012-December/010799.html It's great to see a significant open-source python project that many of us use on a day-to-day basis get such great funding! Thanks, Jason -- Jason Grout
Greetings, With the help of sankey-toolbox, we can plot sankey-diagrams automaticly: The position of a sankey-object is automaticly calculated based on the position of its prior-object and cannot be given manually; and when a sankey-diagram is initialized, the position of the first sankey-object will be assigned with the input of an axis. (the (0,0)-point will be the center-point of this object) And Here is the situation: i want to draw two sankey-diagrams in the same subplot with a given y-offset, therefore are two coordinate systems with y-offset required. I have tried the 'add_axes' method, but with this method a new subplot is created and there will be a graphic scaling problem. Now this is the question: Is it possible to create a new coordinate system with a given y-offset, without creating new subplot? -- View this message in context: http://matplotlib.1069221.n5.nabble.com/create-an-new-axis-with-y-offset-in-the-same-subplot-tp40006.html Sent from the matplotlib - users mailing list archive at Nabble.com.
On 2012年12月11日 1:24 PM, Timothy Duly wrote: > Thanks Eric, this did the trick. I did not know such a thing existed. > Why "4"? I don't remember exactly what the defaults are for different types of artist, and didn't want to take the time to look, but I think they are all less than 4. So I just picked that as a value that would do the job. Eric > > Tim > > > On Tue, Dec 11, 2012 at 4:35 PM, Eric Firing <ef...@ha... > <mailto:ef...@ha...>> wrote: > > On 2012年12月11日 12:16 PM, Timothy Duly wrote: > > Hi, > > > > I'm running into a problem with overlaying a scatter plot on a > polygon > > that is on a Basemap. The polygon covers up the scatter plot > created by > > the basemap. To show the issue, the simple example below and broken > > down into three steps: 1) creating the map, 2) adding the red > polygon, > > and 3) adding the "x" markers via a scatter plot. You will see > that the > > "x" markers are not on top of the polygon. > > > > Why does the polygon cover up the markers, even though I have the > > markers added after the polygon? Would there be a better way to do > > this? I could set the polygon alpha to, say, 0.5, but this > feature does > > not show when I save it as an eps image. Therefore, I would like to > > keep alpha=1. > > Artists have a zorder attribute that controls the drawing order. Try > adding the kwarg zorder=4 to your scatter call. I think that will take > care of it. (Alternatively you could lower the zorder of the polygon.) > > Eric > > > > > Thanks, > > Tim > > > > from mpl_toolkits.basemap import Basemap > > import numpy as np > > from matplotlib.pyplot import * > > from matplotlib.patches import Polygon > > > > > > # --------------------- > > # Part 1: Draw the map > > # --------------------- > > > > # Hawaii: > > lat_0 = 20.71-8. > > lon_0 = 203.83 > > > > figure(1); clf(); > > m = Basemap(width=2500e3,height=2500e3, > > resolution='l',projection='stere', \ > > lat_ts=lat_0,lat_0=lat_0,lon_0=lon_0) > > > > m.drawcoastlines() > > m.fillcontinents(color='coral',lake_color='aqua') > > > > # draw parallels and meridians: > > m.drawmapboundary(fill_color='aqua') > > > > lats = np.arange(np.floor(m.latmin),np.ceil(m.latmax),2.) > > lons = np.arange(190.,211.,5.) > > m.drawparallels(lats,labels=[True,False,False,False]) > > m.drawmeridians(lons,labels=[False,False,False,True]) > > > > draw(); show() > > > > # --------------------- > > # Part 2: Add a polygon > > # --------------------- > > > > lon_poly = np.array([-160., -150., -150., -160.,]) > > lat_poly = np.array([10., 10., 14., 14.,]) > > X, Y = m(lon_poly, lat_poly) > > xy = np.vstack([X,Y]).T > > > > poly = Polygon(xy, closed=True, \ > > facecolor='red', \ > > linewidth=1., \ > > ) > > > > gca().add_patch(poly) > > > > # --------------------- > > # Part 3: add some 'x' markers > > # --------------------- > > > > lon_markers = np.arange(-168.,-144.,2.) > > lat_markers = np.arange(5.,20.,1.) > > X, Y = np.meshgrid(lon_markers, lat_markers) > > > > x, y = m(X.ravel(), Y.ravel()) > > m.scatter(x,y,marker='x') > > > > draw(); show() > > > > > > > > > ------------------------------------------------------------------------------ > > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > > Remotely access PCs and mobile devices and provide instant support > > Improve your efficiency, and focus on delivering more value-add > services > > Discover what IT Professionals Know. Rescue delivers > > http://p.sf.net/sfu/logmein_12329d2d > > > > > > > > _______________________________________________ > > Matplotlib-users mailing list > > Mat...@li... > <mailto:Mat...@li...> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > >
On Tue, Dec 11, 2012 at 1:16 PM, Benjamin Root <ben...@ou...> wrote: > > > On Tue, Dec 11, 2012 at 2:08 PM, Chloe Lewis <ch...@be...> wrote: >> >> Would it be workable for the default to be proportional to the size of the >> array passed in? (suggested only because I do that myself, when deciding how >> coarse an investigative plot I can get away with.) >> >> &C >> > > That is pretty much what the PR I was referring to does: > > https://github.com/matplotlib/matplotlib/pull/1040 > > It makes it so that the behavior of both plot_surface and plot_wireframe is > the same in this respect. So, by default, the rstride and cstride would be > 1% of the size of your data array. This would make the default for the > recent example be 1, therefore showing every point. I wonder if a > logarithmic default would make sense to better handle large data arrays? > > Thoughts? > Ben Root I hope nobody minds if I chime in here. I'm in favour of making the defaults a little more intelligent that what is implemented at present, i.e, a constant stride for any surface. Any non-trivial scaling law to determine what stride to use will result in more expected behaviour than what our users are currently seeing. Could we do better? Could we have plot_surface try and estimate the stride based on the 'roughness' of the surface to be plotted? This method would grind to a halt for very rough surfaces, so we could default to a scaling law in these cases. What does everyone think about this approach? -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229