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
(13) |
2
(16) |
3
(5) |
4
(6) |
5
(4) |
|
6
|
7
(8) |
8
(4) |
9
(8) |
10
(14) |
11
(20) |
12
(3) |
|
13
(7) |
14
(1) |
15
(1) |
16
(5) |
17
(9) |
18
(5) |
19
|
|
20
|
21
(5) |
22
(7) |
23
(4) |
24
|
25
|
26
|
|
27
(3) |
28
(2) |
29
(8) |
30
(6) |
|
|
|
My understanding is that the proposed change will break at least some existing code, hence my proposal to go the safer route. Also I'm unconvinced by the justification for the change : xlim and autoscalex_on are independant attributes, why then should setting xlim have the side effect of turning autoscalex off ? This is not consistent with how the API works. If I really wanted autoscalex off, I would have specified it. To sum things up: Adding an argument to set_xlim to allow autoscale to be turned off in the same step would be a good idea. But it shouldn't suddenly become the default behaviour. efiring wrote: > > On 06/28/2010 04:42 PM, butterw wrote: >> >> Rather than changing the existing xlim, it would be better to create a >> new >> command xlim2 with the desired behaviour (if needed). > > Why, specifically in this case? > > I'm somewhat reluctant to see that proliferation of methods and functions. > > Is there actually a reasonable use case for the present behavior--is it > advantageous under some circumstances? What sort of code is likely to > depend on it? > > Eric > >> >> >> >> efiring wrote: >>> >>> The present behavior of set_xlim and set_ylim can be surprising because >>> making the values stick for subsequent plotting in the same axes >>> requires manually calling set_autoscalex_on(False) etc. It would seem >>> more logical if set_xlim itself included the call to turn autoscalex >>> off--isn't that what a user would almost always want and expect? >>> >>> Rectifying this would constitute a significant change affecting some >>> existing user code. >>> >>> What are people's thoughts on this? Should the change made? If so, do >>> it abruptly, right now, as part of version 1.0? Or phase it in with a >>> temporary kwarg and/or rcparam? It would be nice to avoid all that >>> complexity, but may be we can't, except by leaving everything as it is >>> now. >>> >>> Eric >>> >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- View this message in context: http://old.nabble.com/should-set_xlim-turn-off-x-autoscaling--tp29007843p29029292.html Sent from the matplotlib - devel mailing list archive at Nabble.com.
On Jun 29, 2010, at 5:08 PM, Andrew Straw <str...@as...> wrote: > John Hunter wrote: >> On Sun, Jun 20, 2010 at 7:56 PM, >>> >>> However, the link to trunk-docs still does not work. >>> >>> http://matplotlib.sourceforge.net/trunk-docs/ >>> >> > > I believe I fixed the issue in svn r8477. > > Now, to fix the false alarm warnings that the buildbot give out so we > catch this earlier. > > Hi to all at the SciPy conference -- I'm sorry I'll miss it this year. > Well the site is up so that is the acid test. Michael, you can refer to this for gallery screenshots and examples. You may also want to provide the link along with the rc announcement for those who want docs and examples. Your 2 min talk is growing :-) Thanks for the quick fix, Andrew.
John Hunter wrote: > On Sun, Jun 20, 2010 at 7:56 PM, Jae-Joon Lee <lee...@gm...> wrote: > >> The issue was related with the change in Sphinx v1.0b2, which I think >> I fixed in r8447. >> At least, the html are built fine and uploaded fine. >> >> However, the link to trunk-docs still does not work. >> >> http://matplotlib.sourceforge.net/trunk-docs/ >> >> Can someone check what's wrong? >> > > Andrew, any chance you can look at this before tomorrow AM? We are > putting out a 1.0 release candidate ahead of scipy, and Michael is > giving a "what's new" talk tomorrow, and it would be nice if he could > illustrate some stuff in the gallery of the trunk-docs I believe I fixed the issue in svn r8477. Now, to fix the false alarm warnings that the buildbot give out so we catch this earlier. Hi to all at the SciPy conference -- I'm sorry I'll miss it this year. -Andrew
I just thought of a possible interaction issue that might have to be sorted
out. If we want a .set_xlim() to firmly establish the data limits, what
about a future (or previous) call to ax.set_aspect('equal', 'datalim')?
This causes the data limits to change within the figure box.
Ben Root
On Mon, Jun 28, 2010 at 10:48 PM, Anne Archibald <aar...@ph...
> wrote:
> On 28 June 2010 23:11, Eric Firing <ef...@ha...> wrote:
> > On 06/28/2010 04:42 PM, butterw wrote:
> >>
> >> Rather than changing the existing xlim, it would be better to create a
> new
> >> command xlim2 with the desired behaviour (if needed).
> >
> > Why, specifically in this case?
> >
> > I'm somewhat reluctant to see that proliferation of methods and
> functions.
> >
> > Is there actually a reasonable use case for the present behavior--is it
> > advantageous under some circumstances? What sort of code is likely to
> > depend on it?
>
> The present behaviour bites me every time. I keep forgetting that the
> xlim has to be last and plotting afterward. So I'd prefer this change.
> But let me be the devil's advocate.
>
> Suppose I want to plot a number of different things, with autoscaling
> so that the plot fits them all. This won't change. Now suppose I want
> the "autoscaling" to actually include, for each plotting action,
> explicitly set x and y limits. This still won't change. But if I want
> to omit some of the x and y limits, then the behaviour might change.
> That is, if I have some framework designed to plot several things in a
> row on the same plot, and if that framework sometimes calls xlim/ylim
> when new things are added, but not always, then I might find this
> change an unpleasant surprise.
>
> I'd be inclined to handle this with a warning - if possible, one that
> was triggered only when drawing something that would have triggered a
> rescaling but now no longer does. If that's infeasible, my inclination
> would be to just change it. But I won't be the one who's stuck dealing
> with a stream of puzzled users...
>
> Anne
>
> > Eric
> >
> >>
> >>
> >>
> >> efiring wrote:
> >>>
> >>> The present behavior of set_xlim and set_ylim can be surprising because
> >>> making the values stick for subsequent plotting in the same axes
> >>> requires manually calling set_autoscalex_on(False) etc. It would seem
> >>> more logical if set_xlim itself included the call to turn autoscalex
> >>> off--isn't that what a user would almost always want and expect?
> >>>
> >>> Rectifying this would constitute a significant change affecting some
> >>> existing user code.
> >>>
> >>> What are people's thoughts on this? Should the change made? If so, do
> >>> it abruptly, right now, as part of version 1.0? Or phase it in with a
> >>> temporary kwarg and/or rcparam? It would be nice to avoid all that
> >>> complexity, but may be we can't, except by leaving everything as it is
> >>> now.
> >>>
> >>> Eric
> >>>
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
On Sun, Jun 20, 2010 at 7:56 PM, Jae-Joon Lee <lee...@gm...> wrote: > The issue was related with the change in Sphinx v1.0b2, which I think > I fixed in r8447. > At least, the html are built fine and uploaded fine. > > However, the link to trunk-docs still does not work. > > http://matplotlib.sourceforge.net/trunk-docs/ > > Can someone check what's wrong? Andrew, any chance you can look at this before tomorrow AM? We are putting out a 1.0 release candidate ahead of scipy, and Michael is giving a "what's new" talk tomorrow, and it would be nice if he could illustrate some stuff in the gallery of the trunk-docs JDH
On 28 June 2010 23:11, Eric Firing <ef...@ha...> wrote: > On 06/28/2010 04:42 PM, butterw wrote: >> >> Rather than changing the existing xlim, it would be better to create a new >> command xlim2 with the desired behaviour (if needed). > > Why, specifically in this case? > > I'm somewhat reluctant to see that proliferation of methods and functions. > > Is there actually a reasonable use case for the present behavior--is it > advantageous under some circumstances? What sort of code is likely to > depend on it? The present behaviour bites me every time. I keep forgetting that the xlim has to be last and plotting afterward. So I'd prefer this change. But let me be the devil's advocate. Suppose I want to plot a number of different things, with autoscaling so that the plot fits them all. This won't change. Now suppose I want the "autoscaling" to actually include, for each plotting action, explicitly set x and y limits. This still won't change. But if I want to omit some of the x and y limits, then the behaviour might change. That is, if I have some framework designed to plot several things in a row on the same plot, and if that framework sometimes calls xlim/ylim when new things are added, but not always, then I might find this change an unpleasant surprise. I'd be inclined to handle this with a warning - if possible, one that was triggered only when drawing something that would have triggered a rescaling but now no longer does. If that's infeasible, my inclination would be to just change it. But I won't be the one who's stuck dealing with a stream of puzzled users... Anne > Eric > >> >> >> >> efiring wrote: >>> >>> The present behavior of set_xlim and set_ylim can be surprising because >>> making the values stick for subsequent plotting in the same axes >>> requires manually calling set_autoscalex_on(False) etc. It would seem >>> more logical if set_xlim itself included the call to turn autoscalex >>> off--isn't that what a user would almost always want and expect? >>> >>> Rectifying this would constitute a significant change affecting some >>> existing user code. >>> >>> What are people's thoughts on this? Should the change made? If so, do >>> it abruptly, right now, as part of version 1.0? Or phase it in with a >>> temporary kwarg and/or rcparam? It would be nice to avoid all that >>> complexity, but may be we can't, except by leaving everything as it is >>> now. >>> >>> Eric >>> >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On 06/28/2010 04:42 PM, butterw wrote: > > Rather than changing the existing xlim, it would be better to create a new > command xlim2 with the desired behaviour (if needed). Why, specifically in this case? I'm somewhat reluctant to see that proliferation of methods and functions. Is there actually a reasonable use case for the present behavior--is it advantageous under some circumstances? What sort of code is likely to depend on it? Eric > > > > efiring wrote: >> >> The present behavior of set_xlim and set_ylim can be surprising because >> making the values stick for subsequent plotting in the same axes >> requires manually calling set_autoscalex_on(False) etc. It would seem >> more logical if set_xlim itself included the call to turn autoscalex >> off--isn't that what a user would almost always want and expect? >> >> Rectifying this would constitute a significant change affecting some >> existing user code. >> >> What are people's thoughts on this? Should the change made? If so, do >> it abruptly, right now, as part of version 1.0? Or phase it in with a >> temporary kwarg and/or rcparam? It would be nice to avoid all that >> complexity, but may be we can't, except by leaving everything as it is >> now. >> >> Eric >> >
Rather than changing the existing xlim, it would be better to create a new command xlim2 with the desired behaviour (if needed). efiring wrote: > > The present behavior of set_xlim and set_ylim can be surprising because > making the values stick for subsequent plotting in the same axes > requires manually calling set_autoscalex_on(False) etc. It would seem > more logical if set_xlim itself included the call to turn autoscalex > off--isn't that what a user would almost always want and expect? > > Rectifying this would constitute a significant change affecting some > existing user code. > > What are people's thoughts on this? Should the change made? If so, do > it abruptly, right now, as part of version 1.0? Or phase it in with a > temporary kwarg and/or rcparam? It would be nice to avoid all that > complexity, but may be we can't, except by leaving everything as it is > now. > > Eric > -- View this message in context: http://old.nabble.com/should-set_xlim-turn-off-x-autoscaling--tp29007843p29016365.html Sent from the matplotlib - devel mailing list archive at Nabble.com.