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
(9) |
3
(6) |
4
(2) |
5
(19) |
6
(7) |
7
(3) |
8
(5) |
9
(6) |
10
(13) |
11
(19) |
12
(16) |
13
(9) |
14
(17) |
15
(5) |
16
(12) |
17
(12) |
18
(5) |
19
(16) |
20
(10) |
21
(9) |
22
(3) |
23
(8) |
24
(5) |
25
(13) |
26
(11) |
27
(21) |
28
(9) |
29
(11) |
30
(6) |
31
(5) |
|
|
|
|
Hi all, recently I have implemented some new functionality for the free geometric software SpaceFuncs <http://openopt.org/SpaceFuncs> and would like to introduce a couple of optimization examples with Olympic rings, devoted to the Olympic games - 2012, that are going on now. They are valid for upcoming <http://openopt.org/coming> version of SpaceFuncs <http://openopt.org/SpaceFuncs> only (already available in subversion repository). In similar way you can solve systems of linear/nonlinear geometrical (in any space dimension) equations (see OpenOpt SLE <http://openopt.org/SLE> and SNLE <http://openopt.org/SNLE>). Graphical output is powered by matplotlib <http://matplotlib.sourceforge.net/>. 1. Let's search 5 points (1 from each ring) that form polygon with maximum area. Code is here <http://openopt.org/SpaceFuncsDoc#An_example_with_olympic_circles> (or here <http://trac.openopt.org/openopt/browser/PythonPackages/SpaceFuncs/examples/maxArea.py>). max area 2. Well, (1) was quite easy problem that could be done by many ways with many different software. Let's consider more difficult example. Suppose we have several points with different positive or negative weights and would like to place them in the olympic circles so that their centroid (barycenter) would be as close to a target as possible; let's also demand distance between any 2 points has to be no less than 0.15. It is difficult combinatorial optimization problem - each point may belong to one of 5 circles, so number of possibilities is 5^m, where m is number of points; moreover, we have m * (m-1) / 2 difficult nonlinear nonconvex equality constraints (requirements on distances). Fortunately, OpenOpt has awesome solver interalg <http://openopt.org/interalg>, that easily solves this problem (for quite small m, although), moreover, with specifiable accuracy fTol: abs(f-f*) <= fTol; we will consider 3 points of weights [15, -0.15, 3]. Code is here <http://openopt.org/SpaceFuncsDoc#Another_example_with_olympic_circles> (or here <http://trac.openopt.org/openopt/browser/PythonPackages/SpaceFuncs/examples/centroid.py>) centroid Best wishes for you country in the Olympic games, D. ------------------------------------ http://openopt.org/Dmitrey
Hi, 2012年7月30日 oc-spam65 <oc-...@la...>: > Hello, > > Can the 'zorder' of the ticks be set? This minimal example shows a > hard-coded value of 2.5 > > This may come from file "matplotlib/axes.py", function "draw()". Can it > be adjusted? Shall it be bug-reported? > > ####################################################################### > import matplotlib.pyplot as pyplot > > fig = pyplot.figure() > ax = fig.add_subplot("111") > > ax.add_patch(pyplot.Rectangle((0,0), 1, 1, zorder=3)) > ax.xaxis.set_zorder(4) > # Expected behavior: the ticks should be drawn after the Rectangle, > # because 4 > 3. They should therefore be visible. > > pyplot.show() > # Problem: The ticks are hidden by the rectangle, contrary to the > # expected behavior. > > print(ax.xaxis.get_zorder()) > # Prints 2.5 instead of 4! > > ####################################################################### I confirm the bug on matplotlib v: 1.1.0, Kubuntu 11.04, Python 2.7.1+ >>> ax.xaxis.set_zorder(4) >>> ax.xaxis.get_zorder() >>>> 4 >>> plt.draw() >>> ax.xaxis.get_zorder() It seems that the call to draw or show sets the zorder to default, instead of updating it. @Mr Spam (can you sign your mail, please) In one of my scripts managed to set zorder to the spines as, e.g., ax.spines['left'].set_zorder(101). This puts the axis spine well on top, but ax.xaxis.set_zorder does nothing. I've also found a method ax.tick_params, that has a zorder keyword, but it does nothing too. Cheers, Francesco > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Hello, Can the 'zorder' of the ticks be set? This minimal example shows a hard-coded value of 2.5 This may come from file "matplotlib/axes.py", function "draw()". Can it be adjusted? Shall it be bug-reported? ####################################################################### import matplotlib.pyplot as pyplot fig = pyplot.figure() ax = fig.add_subplot("111") ax.add_patch(pyplot.Rectangle((0,0), 1, 1, zorder=3)) ax.xaxis.set_zorder(4) # Expected behavior: the ticks should be drawn after the Rectangle, # because 4 > 3. They should therefore be visible. pyplot.show() # Problem: The ticks are hidden by the rectangle, contrary to the # expected behavior. print(ax.xaxis.get_zorder()) # Prints 2.5 instead of 4! #######################################################################
I'd agree as then it would work as pcolormesh or imshow does which when passed in the same norm will only set vmin or vmax that wasn't previously set. Assume this would be a really easy fix but I can have a look at submitting a patch if someone else isn't going to do so just let me know. Cheers, Jeff On Mon, Jul 30, 2012 at 2:31 AM, Eric Firing <ef...@ha...> wrote: > On 2012年07月29日 5:13 AM, Jeffrey Spencer wrote: > >> Eric, >> >> Normalize appears to be working correctly and as you stated above but >> when passed into contourf appears to have inconsistent results not >> following the docstring by allowing the value to change. >> >> Quick examples: >> >> X, Y = meshgrid(arange(20),arange(20)**) >> Z = arange(20*20) >> Z = Z.reshape(20,20) >> norm = colors.Normalize(vmin=200,**vmax=None) >> print norm.vmin >> fig = figure(10) >> ax = fig.add_subplot(111) >> surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = norm) >> >> This vmin has no effect where if you pass in: >> >> X, Y = meshgrid(arange(20),arange(20)**) >> Z = arange(20*20) >> Z = Z.reshape(20,20) >> norm = colors.Normalize(vmin=200,**vmax=Z.max()) >> print norm.vmin >> fig = figure(10) >> ax = fig.add_subplot(111) >> surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = norm) >> >> it has the desired effect. >> >> Let me know if this is correct or I'm missing something here. >> >> Cheers, >> Jeff >> > > You are correct. Contour and contourf are respecting vmin, vmax that have > been set in the norm only if both have been set, so that it is fully > scaled. I think that changing this to respect a single preset vmin or vmax > would be reasonable. > > Eric > >
Hello List, I am trying to determine the position of the axes after an imshow and am having problems. I get a different answer on my Mac (the correct answer) than Windows (the wrong answer). I have a file called testimage.py with 5 lines: from pylab import * c = ones((10,20)) ax = imshow(c) show() print ax.get_axes().get_position() I run this file from IPython. On my Mac I get: run testimage Bbox(array([[ 0.125 , 0.24166667], [ 0.9 , 0.75833333]])) On Windows I get (the wrong answer): run testimage Bbox(array([[ 0.125, 0.1 ], [0.9, 0.9 ]])) Any thoughts? When I type the commands in at the IPython prompt it works most of the time (on Windows), but it never works when running the file. What in the world could be different? mp version 1.1.0 on both systems. Thanks for your help, Mark
When using an equidistant cylindrical projection over a selected subregion of the globe, e.g. map = Basemap(llcrnrlon=50,llcrnrlat=-80,urcrnrlon=300,urcrnrlat=70,projection='cyl'), any contour plot that I try and generate (i.e. any plot generated using the map.contour() function) cannot plot any values south of 10N. In other words, everything south of 10N just shows up blank on the plot. It works fine for filled contours (i.e. map.contourf()), but not for simple contour lines (map.contour()). Has anyone else come across this issue?