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
(22) |
2
(17) |
3
(21) |
4
(7) |
5
(7) |
6
(17) |
7
(8) |
8
(8) |
9
(33) |
10
(11) |
11
|
12
(2) |
13
(11) |
14
(29) |
15
(13) |
16
(13) |
17
(3) |
18
(2) |
19
(3) |
20
(7) |
21
(17) |
22
(12) |
23
(19) |
24
(19) |
25
(14) |
26
(5) |
27
(25) |
28
(13) |
|
|
|
|
From: Eric F. <ef...@ha...> - 2006-02-01 08:36:31
|
Christopher Barker wrote: > Christopher Barker wrote: > >> Maybe I'll try to make a small sample that demonstrates the issue. >> stay tuned. > > > OK, read the previous posts for background, or ignore them, and just > read this one. I made a small sample, and found that using a > LineCollection with axes.add_collection does something weird to the data > limits that axes sets. I've enclosed a small sample that demonstrates > the problem. Chris, Attached is a slight modification of your test case, with annotations. I think it does what you want--sort of. But I agree that there is a bug. After chasing references backwards and forwards through axes.py, axis.py, ticker.py, and _transforms.cpp, I don't quite understand how everything works, but I think this is part of the problem: axes.has_data() is being used to determine whether to update the dataLim from scratch, or to start with previous values. axes.has_data() is True if any drawing artist (Line, Collection, etc.) has been added to the axes. So, after clearing the axes, adding a LineCollection tells the dataLim update method (called by the subsequent plot()) to use the old information, even though Collections (unlike Lines) do not change the dataLim. In other words, in your original script, I think that adding the collection was preventing plot() from setting the axes to a smaller value. Workarounds: either set the dataLim explicitly, or add the collection after the plot command (as in the attached modified script). The latter only works if the plot command sets the dataLim to be large enough to cover everything in the collection. I would like to make a genuine bugfix, but I do not yet understand all this well enough to do so right now. Maybe John will chime in with a good solution. Eric |
From: Christopher B. <Chr...@no...> - 2006-02-01 01:01:23
|
Just for the record, I've solved all this, for the moment, by clearing the entire figure, and starting again with a brand new axes. It does seem like there's a bug in the axes.clear() method, however, I should be able to just .clear() and add stuff again, shouldn't I? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Christopher B. <Chr...@no...> - 2006-02-01 00:44:18
|
Christopher Barker wrote: > Maybe I'll try to make a small sample that demonstrates the issue. stay > tuned. OK, read the previous posts for background, or ignore them, and just read this one. I made a small sample, and found that using a LineCollection with axes.add_collection does something weird to the data limits that axes sets. I've enclosed a small sample that demonstrates the problem. Here is the plotting code itself: # Do some plotting ax.plot(offsets[:,0], offsets[:,1], 'o') # clear the axes, and try again, with different data. ax.clear() offsets *= .1 coll = LineCollection(segments, offsets=offsets, transOffset=ax.transData, # transforms the x,y offsets ) # points/72.*dpi = pixels -- see matplotlib.transforms trans = scale_transform(fig.dpi/Value(72.), fig.dpi/Value(72.)) coll.set_transform(trans) # the points to pixels transform ax.add_collection(coll) ax.plot(offsets[:,0], offsets[:,1], 'o') ax.autoscale_view() pylab.show() running this, you get the axes set to data limits appropriate to the first ax.plot call, before the ax.clear() call. (the second has values 1/10 as large. However, if you don't do the first plot call, it all scales correctly. Now it's even weirder. If you do the first plot call (with the larger data), but comment out add_collection() call, it scales correctly. So it seems that using add_collection someone fixes the data limits to the previous value, even after the ax.clear() call. AFAICT, looking at the axes class code, this shouldn't happen. add_collection doesn't do much at all. Also, after axes.clear() is called, ax.has_data() returns False, so when axes.update_datalim is called, the old dataLim should be ignored. by the way, it looks like axes.cla() should perhaps have this in it: self.dataLim = unit_bbox() or maybe: self._set_lim_and_transforms() I've gotten a bit lost in all this: HELP! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |