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
(5) |
3
(16) |
4
(18) |
5
(11) |
6
(5) |
7
|
8
(5) |
9
(10) |
10
(24) |
11
(37) |
12
(10) |
13
(6) |
14
|
15
(5) |
16
(3) |
17
|
18
(8) |
19
(6) |
20
(3) |
21
(5) |
22
(4) |
23
(14) |
24
(5) |
25
(12) |
26
(18) |
27
(6) |
28
|
29
(4) |
30
(1) |
31
(16) |
|
|
|
Chris, I suspect it is a problem with your matplotlibrc file; you could try stripping it down to bare minimum, as in the svn root directory. Another possibility is that your update is somehow incomplete or scrambled with an earlier installation. If that doesn't work, try making a minimal script that illustrates the problem. examples/newscalarformatter_demo.py works fine, so I don't think the basic subplot mechanism is broken. Chris Fonnesbeck wrote: > I have just updated to a matplotlib build from SVN, and now all my > subplots generate errors: > > (Pdb) rows > Out[3]: 2 > (Pdb) columns > Out[3]: 2 > (Pdb) num > Out[3]: 1 > (Pdb) subplot(rows, columns, num) > *** KeyError: 'axes.formatter.limits' I think this is a valid key in rcParams. Doesn't the error trigger a full traceback that shows where it is coming from? Eric > > I really dont know why this is happening, so I would appreciate any > assistance. > > Thanks, > Chris > > -- > Chris Fonnesbeck + Atlanta, GA + http://trichech.us
Thanks Eric. I'll give it a shot, Mark On 1/6/07, Eric Firing <ef...@ha...> wrote: > > Mark Bakker wrote: > > Eric - > > > > Yeah, I agree. The words 'equal' is confusing. But it was taken from > > matlab. 'scaled' was my invention/doing. I thought it was better than > > 'equal', as it makes the scales equal on both axes. Either way, I would > > like it if we can fix the data limits in a simple way, and I think > > incorporating it in 'scaled' would be one option. A new option would be > > a good idea too. Something like 'scaledfixed' ? Maybe too long. Or just > > 'scaledf' ? Code is simple: > > > > elif s == 'scaledf': > > self.set_aspect('equal', adjustable='box', > anchor='C') > > self.set_autoscale_on(False) > > No one else said anything about this, so I suspect that you may be the > only person using 'scaled' now. Given that you invented it, and that it > was present for a while in your original form, I decided to simply > restore it to that rather than to introduce another option. There are > potentially too many combinations to have a short name for each. > > This is not irrevocable, of course. > > I had to make a slight change in apply_aspect so that toggling back and > forth between this version of scaled and equal would work; I hope that > hasn't fouled up anything else. I think it should be OK. > > Eric > > > > > Thanks, > > > > Mark > > > > > > On 1/3/07, *Eric Firing* <ef...@ha... > > <mailto:ef...@ha...>> wrote: > > > > Mark Bakker wrote: > > > The enhanced way of handling aspect ratios that Eric implemented > > works > > > great. > > > There is, however, one change from the old implementation that I > > don't like. > > > > > > In the old implementation, when setting axis('scaled') it also > > turned > > > autoscale off. > > > This makes sense (and I used it a lot). It means that you can set > the > > > axis('scaled'), which means the aspect ratios are set equal and > > the axis > > > limits are not changed, at any point when you like the data > > limits. The > > > axis limits are then fixed so that every time you add something > > else to > > > the figure it will keep these limits. > > > > > > In the new implementation (ok, it has been there for a little > while > > > now), you have to give a separate set_autoscale_on(False) > command. > > > Besides the odd name of the function (you actually turn the > autoscale > > > off), it is a command that should be set right away by > > axis('scaled'). > > > If you want the autoscale to remain on, you should use > axis('equal') > > > > Here is the present code fragment (slightly mangled by the mailer): > > > > elif s in ('equal', 'tight', 'scaled', 'normal', > 'auto', > > 'image'): > > self.set_autoscale_on(True) > > self.set_aspect('auto') > > self.autoscale_view() > > self.apply_aspect() > > if s=='equal': > > self.set_aspect('equal', adjustable='datalim') > > elif s == 'scaled': > > self.set_aspect('equal', adjustable='box', > > anchor='C') > > elif s=='tight': > > self.autoscale_view(tight=True) > > self.set_autoscale_on(False) > > elif s == 'image': > > self.autoscale_view(tight=True) > > self.set_autoscale_on(False) > > self.set_aspect('equal', adjustable='box', > > anchor='C') > > > > At present, the difference between "equal" and "scaled" is not the > > autoscale state but the "adjustable". > > > > I don't have any objection to changing the behavior of "scaled" as > you > > suggest, if that is what people want. Alternatively, yet another > word > > could be used to define the behavior you want, and that behavior > could > > be added. I don't find "scaled" or "equal" very descriptive or > > intuitive; nor do I find that either word suggests how autoscale > should > > be set. (And I agree, "set_autoscale_on(False)" is ugly.) > > > > Eric > > > > > >
I have just updated to a matplotlib build from SVN, and now all my subplots generate errors: (Pdb) rows Out[3]: 2 (Pdb) columns Out[3]: 2 (Pdb) num Out[3]: 1 (Pdb) subplot(rows, columns, num) *** KeyError: 'axes.formatter.limits' I really dont know why this is happening, so I would appreciate any assistance. Thanks, Chris -- Chris Fonnesbeck + Atlanta, GA + http://trichech.us
Mark Bakker wrote: > Eric - > > Yeah, I agree. The words 'equal' is confusing. But it was taken from > matlab. 'scaled' was my invention/doing. I thought it was better than > 'equal', as it makes the scales equal on both axes. Either way, I would > like it if we can fix the data limits in a simple way, and I think > incorporating it in 'scaled' would be one option. A new option would be > a good idea too. Something like 'scaledfixed' ? Maybe too long. Or just > 'scaledf' ? Code is simple: > > elif s == 'scaledf': > self.set_aspect('equal', adjustable='box', anchor='C') > self.set_autoscale_on(False) No one else said anything about this, so I suspect that you may be the only person using 'scaled' now. Given that you invented it, and that it was present for a while in your original form, I decided to simply restore it to that rather than to introduce another option. There are potentially too many combinations to have a short name for each. This is not irrevocable, of course. I had to make a slight change in apply_aspect so that toggling back and forth between this version of scaled and equal would work; I hope that hasn't fouled up anything else. I think it should be OK. Eric > > Thanks, > > Mark > > > On 1/3/07, *Eric Firing* <ef...@ha... > <mailto:ef...@ha...>> wrote: > > Mark Bakker wrote: > > The enhanced way of handling aspect ratios that Eric implemented > works > > great. > > There is, however, one change from the old implementation that I > don't like. > > > > In the old implementation, when setting axis('scaled') it also > turned > > autoscale off. > > This makes sense (and I used it a lot). It means that you can set the > > axis('scaled'), which means the aspect ratios are set equal and > the axis > > limits are not changed, at any point when you like the data > limits. The > > axis limits are then fixed so that every time you add something > else to > > the figure it will keep these limits. > > > > In the new implementation (ok, it has been there for a little while > > now), you have to give a separate set_autoscale_on(False) command. > > Besides the odd name of the function (you actually turn the autoscale > > off), it is a command that should be set right away by > axis('scaled'). > > If you want the autoscale to remain on, you should use axis('equal') > > Here is the present code fragment (slightly mangled by the mailer): > > elif s in ('equal', 'tight', 'scaled', 'normal', 'auto', > 'image'): > self.set_autoscale_on(True) > self.set_aspect('auto') > self.autoscale_view() > self.apply_aspect() > if s=='equal': > self.set_aspect('equal', adjustable='datalim') > elif s == 'scaled': > self.set_aspect('equal', adjustable='box', > anchor='C') > elif s=='tight': > self.autoscale_view(tight=True) > self.set_autoscale_on(False) > elif s == 'image': > self.autoscale_view(tight=True) > self.set_autoscale_on(False) > self.set_aspect('equal', adjustable='box', > anchor='C') > > At present, the difference between "equal" and "scaled" is not the > autoscale state but the "adjustable". > > I don't have any objection to changing the behavior of "scaled" as you > suggest, if that is what people want. Alternatively, yet another word > could be used to define the behavior you want, and that behavior could > be added. I don't find "scaled" or "equal" very descriptive or > intuitive; nor do I find that either word suggests how autoscale should > be set. (And I agree, "set_autoscale_on(False)" is ugly.) > > Eric > >
On Fri, Jan 05, 2007 at 04:23:53PM -0600, Glen W. Mabey wrote: > Contrary to the comments in the default matplotlibrc, it seems that > font.size does not set the fontsize for axis labels and ticks; you have > to set [xy]tick.labelsize and axes.labelsize explicitly. But I haven't > had a chance to look into that ... yet. does fontweight = "..." work for you? I couldn't get that one to work cs