You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
1
|
2
|
3
|
4
(1) |
5
(3) |
6
|
7
(7) |
8
(5) |
9
(10) |
10
(3) |
11
(5) |
12
(1) |
13
|
14
|
15
(1) |
16
(2) |
17
(7) |
18
(6) |
19
(8) |
20
(2) |
21
|
22
(3) |
23
(2) |
24
|
25
|
26
|
27
|
28
|
29
|
30
(4) |
|
|
|
|
On Mon, Nov 22, 2010 at 3:30 AM, Ian Thomas <ian...@gm...> wrote: > I've found a bug in mplot3d's rendering of filled contours. Attached is a > simple test script to reproduce the error and an example of the output: the > 2D plot on the left shows the desired result, the 3D plot on the right shows > the holes in the contour are not rendered correctly. > > Digging around in axes3d.py and art3d.py, I think the problem is that > mplot3d ignores the 'codes' that are produced by the 2D contourf routine. I > am probably not using the correct terminology, but I understand that these > codes allow a polygon to be composed of multiple line loops, some of which > may be holes within other line loops. By ignoring the codes, the 3D routine > renders a single polygon by concatenating all the points together regardless > of whether they correspond to a hole or not. > > In revision 8806 of lib/mpl_toolkits/mplot3d/art3d.py, lines 136-7: > > for (((x, y), code), z) in zip(pathsegs, zs): > seg.append((x, y, z)) > > The codes are extracted from the pathsegs (which come from the 2D contourf > routine), but then ignored. > > I've taken a look at trying to fix this, but it was not obvious to me how > to propagate the 'codes' rendering functionality from the 2D to 3D source > code. Perhaps someone more familiar with mplot3d could look at it. > > Thanks, > Ian > > Confirmed. Ian, would you mind filing a bug report on this at mpl's tracker? http://sourceforge.net/tracker/?atid=560720&group_id=80706&func=browse Thank you very much for your insightful analysis as well. It will be helpful in finding a fix for this. Ben Root
On Thu, Nov 18, 2010 at 8:58 AM, Scott Sinclair <sco...@gm... > wrote: > Hi, > > It seems that the autofmt_xdate helper method is broken when twinx is > used. Consider the script below: > > ----------------------------------------- > import datetime as dt > > import numpy as np > import matplotlib.pyplot as plt > from matplotlib.dates import date2num > > strt = dt.datetime(2000, 3, 15, 6) > delta = dt.timedelta(hours=6) > date_list = [(strt + i*delta) for i in range(100)] > > x = date2num(date_list) > y = np.sin(x) > z = np.cos(x) > > fig, ax1 = plt.subplots() > > ax1.plot(date_list, y, 'b-') > > ax2 = ax1.twinx() > ax2.plot(date_list, z, 'r-') > > # using the auto format method doesn't work > fig.autofmt_xdate() > > plt.show() > ----------------------------------------- > > This is because the 'is_last_row' attribute isn't present on ax2 and > len(fig.axes) != 1 when the autofmt_xdate method is called on fig. > > The attached patch fixes it for me and still seems to give the > advertised behaviour for single and vertically stacked subplots. > > Cheers, > Scott > > I am not very familiar with this part of mpl, but your diff seems to cut out a few things. In particular, the original code checks to see if the figure has a single axes object or more. However, your code seems to cut this check out. Now, it may have been that the check could have been unnecessary, but I am not sure. I am curious as to your insight on this. In addition, the original code called "self.subplots_adjust(bottom=bottom)" only when all subplots were on the last row. Now, it seems that it is always called no matter what. Ben Root
I've found a bug in mplot3d's rendering of filled contours. Attached is a simple test script to reproduce the error and an example of the output: the 2D plot on the left shows the desired result, the 3D plot on the right shows the holes in the contour are not rendered correctly. Digging around in axes3d.py and art3d.py, I think the problem is that mplot3d ignores the 'codes' that are produced by the 2D contourf routine. I am probably not using the correct terminology, but I understand that these codes allow a polygon to be composed of multiple line loops, some of which may be holes within other line loops. By ignoring the codes, the 3D routine renders a single polygon by concatenating all the points together regardless of whether they correspond to a hole or not. In revision 8806 of lib/mpl_toolkits/mplot3d/art3d.py, lines 136-7: for (((x, y), code), z) in zip(pathsegs, zs): seg.append((x, y, z)) The codes are extracted from the pathsegs (which come from the 2D contourf routine), but then ignored. I've taken a look at trying to fix this, but it was not obvious to me how to propagate the 'codes' rendering functionality from the 2D to 3D source code. Perhaps someone more familiar with mplot3d could look at it. Thanks, Ian