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
(1) |
2
(10) |
3
(2) |
4
|
5
(2) |
6
|
7
|
8
|
9
(3) |
10
|
11
(1) |
12
(2) |
13
(2) |
14
(5) |
15
(5) |
16
(5) |
17
(1) |
18
(1) |
19
(1) |
20
(5) |
21
(2) |
22
(4) |
23
(1) |
24
(3) |
25
(14) |
26
(6) |
27
(6) |
28
(7) |
29
(2) |
30
|
|
From: Gökhan S. <gok...@gm...> - 2010-04-25 18:36:16
|
On Sun, Apr 25, 2010 at 1:28 PM, Neal Becker <ndb...@gm...> wrote: > savefig works fine. > > Using 'gtk' backend I can save, but seems to have other problems. > > Using recommended TkAgg I get error that > ImportError: No module named backend_tkagg > You will have to make some installations to bring TkAgg alive. I would suggest trying also the Qt4Agg backend since KDE based on Qt. It is always a good idea to use the package manager for these. Let me know if this helps. |
From: Neal B. <ndb...@gm...> - 2010-04-25 18:29:21
|
Gökhan Sever wrote: > On Sun, Apr 25, 2010 at 1:02 PM, Neal Becker > <ndb...@gm...> wrote: > >> Yes, I get this: >> >> kfilemodule(29192)/kio (KDirModel) KDirModelPrivate::_k_slotDeleteItems: >> No node found for item that was just removed: >> KUrl("file:///home/nbecker/test1.cs") >> kfilemodule(29192): couldn't create slave: "Unable to create io-slave: >> klauncher said: Unknown protocol ''. >> " >> kfilemodule(29192): couldn't create slave: "Unable to create io-slave: >> klauncher said: Unknown protocol ''. >> " >> > > Very specific KDE errors. Sorry can't comment on these errors. > > >> >> Have not tried savefig or other backend. (Have to learn how to use >> savefig first) >> > > These are easy. Within IPython -pylab run your script with run myscript.py > . Then do a plt.savefig("myplot.png") or whatever extension available to > you. To change the backend go into your .matplotlib directory and edit > matplotlibrc file. Find backend keyword and experiment with the available > backends to see if you can reproduce that error. > savefig works fine. Using 'gtk' backend I can save, but seems to have other problems. Using recommended TkAgg I get error that ImportError: No module named backend_tkagg |
From: Miguel de V. B. <mig...@gm...> - 2010-04-25 18:21:45
|
Hello, The amplitude of sharp peaks is not shown correctly when several plots are stitched together and the x scale becomes very large. I have noticed this problem with the pdf and png backends in the attached script. Best regards, Miguel |
From: Gökhan S. <gok...@gm...> - 2010-04-25 18:11:01
|
On Sun, Apr 25, 2010 at 1:02 PM, Neal Becker <ndb...@gm...> wrote: > Yes, I get this: > > kfilemodule(29192)/kio (KDirModel) KDirModelPrivate::_k_slotDeleteItems: No > node found for item that was just removed: > KUrl("file:///home/nbecker/test1.cs") > kfilemodule(29192): couldn't create slave: "Unable to create io-slave: > klauncher said: Unknown protocol ''. > " > kfilemodule(29192): couldn't create slave: "Unable to create io-slave: > klauncher said: Unknown protocol ''. > " > Very specific KDE errors. Sorry can't comment on these errors. > > Have not tried savefig or other backend. (Have to learn how to use savefig > first) > These are easy. Within IPython -pylab run your script with run myscript.py . Then do a plt.savefig("myplot.png") or whatever extension available to you. To change the backend go into your .matplotlib directory and edit matplotlibrc file. Find backend keyword and experiment with the available backends to see if you can reproduce that error. -- Gökhan |
From: Neal B. <ndb...@gm...> - 2010-04-25 18:02:53
|
Gökhan Sever wrote: > On Sun, Apr 25, 2010 at 12:52 PM, Neal Becker > <ndb...@gm...> wrote: > >> Yes, I meant the 'save' button in the upper right. >> >> It used to work, but some update seems to have broken it. Strange, so >> far the only application that shows a problem like this (and I do use a >> lot of different apps!) >> > > Do you get any error messages behind the scenes? Does it work when you > save the plot using savefig? Is it same with different backends? I am on > GNOME. You seem to like using KDE, right? > Yes, I get this: kfilemodule(29192)/kio (KDirModel) KDirModelPrivate::_k_slotDeleteItems: No node found for item that was just removed: KUrl("file:///home/nbecker/test1.cs") kfilemodule(29192): couldn't create slave: "Unable to create io-slave: klauncher said: Unknown protocol ''. " kfilemodule(29192): couldn't create slave: "Unable to create io-slave: klauncher said: Unknown protocol ''. " Yes, I am on KDE. Have not tried savefig or other backend. (Have to learn how to use savefig first) |
From: Gökhan S. <gok...@gm...> - 2010-04-25 17:57:36
|
On Sun, Apr 25, 2010 at 12:52 PM, Neal Becker <ndb...@gm...> wrote: > Yes, I meant the 'save' button in the upper right. > > It used to work, but some update seems to have broken it. Strange, so far > the only application that shows a problem like this (and I do use a lot of > different apps!) > Do you get any error messages behind the scenes? Does it work when you save the plot using savefig? Is it same with different backends? I am on GNOME. You seem to like using KDE, right? -- Gökhan |
From: Neal B. <ndb...@gm...> - 2010-04-25 17:52:35
|
Gökhan Sever wrote: > On Sun, Apr 25, 2010 at 12:33 PM, Neal Becker > <ndb...@gm...> wrote: > >> python-matplotlib-0.99.1.2-1.fc12.x86_64 >> >> When I hit 'print' button, I get a partially painted dialog. Screenshot >> attached. This is repeatable on 2 different machines. >> > > I am on Fedora 12. Where is print button in matplotlib? You meant the save > dialog? If that's the case I don't see any problem using the svn version > of mpl. > > I build sources manually -> > http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-svn > > Similarly I build numpy and scipy from sources too. If available I use > easy_install for some packages, otherwise mostly manual builds. (Except > the Python itself.) This might be confusing since I use the package > manager to install dependencies most of the time. Once in a while I see > some packages requiring older numpy builds, also when I try to uninstall > some packages via package manager it tries to uninstall more packages (the > critical ones) than what is installed. Not always required but manual > builds give more control and easy to manage on some occurrences like in > matplotlib build case. > Yes, I meant the 'save' button in the upper right. It used to work, but some update seems to have broken it. Strange, so far the only application that shows a problem like this (and I do use a lot of different apps!) |
From: Gökhan S. <gok...@gm...> - 2010-04-25 17:48:56
|
On Sun, Apr 25, 2010 at 12:33 PM, Neal Becker <ndb...@gm...> wrote: > python-matplotlib-0.99.1.2-1.fc12.x86_64 > > When I hit 'print' button, I get a partially painted dialog. Screenshot > attached. This is repeatable on 2 different machines. > I am on Fedora 12. Where is print button in matplotlib? You meant the save dialog? If that's the case I don't see any problem using the svn version of mpl. I build sources manually -> http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-svn Similarly I build numpy and scipy from sources too. If available I use easy_install for some packages, otherwise mostly manual builds. (Except the Python itself.) This might be confusing since I use the package manager to install dependencies most of the time. Once in a while I see some packages requiring older numpy builds, also when I try to uninstall some packages via package manager it tries to uninstall more packages (the critical ones) than what is installed. Not always required but manual builds give more control and easy to manage on some occurrences like in matplotlib build case. -- Gökhan |
From: Neal B. <ndb...@gm...> - 2010-04-25 17:33:57
|
python-matplotlib-0.99.1.2-1.fc12.x86_64 When I hit 'print' button, I get a partially painted dialog. Screenshot attached. This is repeatable on 2 different machines. |
From: Michiel de H. <mjl...@ya...> - 2010-04-25 08:28:24
|
Eric, Tony, thanks for your replies. I'll look at SciPy then for this functionality. Thanks, --Michiel. --- On Sat, 4/24/10, Eric Firing <ef...@ha...> wrote: > From: Eric Firing <ef...@ha...> > Subject: Re: [matplotlib-devel] Lowess smoothing > To: "Michiel de Hoon" <mjl...@ya...> > Cc: mat...@li... > Date: Saturday, April 24, 2010, 2:29 PM > Michiel de Hoon wrote: > > Hi everybody, > > > > A number of years ago I wrote a function to do Lowess > smoothing to calculate a smooth curve through a scatter > plot. I copied an example script below and attached the > resulting figure to this mail. > > I think that such a smoothing function would be a > useful addition to matplotlib. Does anybody have any > objections against me adding this to matplotlib? If not, > what would be a suitable place to put this function? > > > > --Michiel. > > > > Michiel, > > Certainly it would be good to have that function available, > but I'm not in favor of putting it in mpl. The trend > has been to try to reduce overlap among mpl, numpy, and > scipy. To that end, scipy seems like the natural home > for smoothing functions. > > Eric > > > > > from pylab import * > > > > x = arange(0,10,0.01) > > ytrue = exp(-x/5.0) + 2*sin(x/3.0) > > > > # add random errors with a normal distribution > > y = ytrue + normal(size=len(x)) > > scatter(x,y,color='cyan') > > > > # calculate a smooth curve through the scatter plot > > ys = smooth(x, y, 'lowess') > > plot(x,ys,'red',linewidth=3) > > > > # draw the true values for comparison > > plot(x,ytrue,'green',linewidth=3) > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------------ > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
From: Eric F. <ef...@ha...> - 2010-04-24 18:29:54
|
Michiel de Hoon wrote: > Hi everybody, > > A number of years ago I wrote a function to do Lowess smoothing to calculate a smooth curve through a scatter plot. I copied an example script below and attached the resulting figure to this mail. > I think that such a smoothing function would be a useful addition to matplotlib. Does anybody have any objections against me adding this to matplotlib? If not, what would be a suitable place to put this function? > > --Michiel. > Michiel, Certainly it would be good to have that function available, but I'm not in favor of putting it in mpl. The trend has been to try to reduce overlap among mpl, numpy, and scipy. To that end, scipy seems like the natural home for smoothing functions. Eric > > from pylab import * > > x = arange(0,10,0.01) > ytrue = exp(-x/5.0) + 2*sin(x/3.0) > > # add random errors with a normal distribution > y = ytrue + normal(size=len(x)) > scatter(x,y,color='cyan') > > # calculate a smooth curve through the scatter plot > ys = smooth(x, y, 'lowess') > plot(x,ys,'red',linewidth=3) > > # draw the true values for comparison > plot(x,ytrue,'green',linewidth=3) > > > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: Tony S Yu <ts...@gm...> - 2010-04-24 13:23:54
|
On Apr 24, 2010, at 4:25 AM, Michiel de Hoon wrote: > Hi everybody, > > A number of years ago I wrote a function to do Lowess smoothing to calculate a smooth curve through a scatter plot. I copied an example script below and attached the resulting figure to this mail. > I think that such a smoothing function would be a useful addition to matplotlib. Does anybody have any objections against me adding this to matplotlib? If not, what would be a suitable place to put this function? I'm not a matplotlib developer, but smoothing seems more appropriate for scipy. There's been some talk of starting a scikit for smoothing functions (see links below), but I'm not sure if anyone has the motivation to actually take the lead. -Tony http://mail.scipy.org/pipermail/scipy-user/2010-February/024402.html http://mail.scipy.org/pipermail/scipy-user/2010-February/024408.html |
From: Michiel de H. <mjl...@ya...> - 2010-04-24 08:25:52
|
Hi everybody, A number of years ago I wrote a function to do Lowess smoothing to calculate a smooth curve through a scatter plot. I copied an example script below and attached the resulting figure to this mail. I think that such a smoothing function would be a useful addition to matplotlib. Does anybody have any objections against me adding this to matplotlib? If not, what would be a suitable place to put this function? --Michiel. from pylab import * x = arange(0,10,0.01) ytrue = exp(-x/5.0) + 2*sin(x/3.0) # add random errors with a normal distribution y = ytrue + normal(size=len(x)) scatter(x,y,color='cyan') # calculate a smooth curve through the scatter plot ys = smooth(x, y, 'lowess') plot(x,ys,'red',linewidth=3) # draw the true values for comparison plot(x,ytrue,'green',linewidth=3) |
From: John H. <jd...@gm...> - 2010-04-23 12:45:05
|
On Thu, Apr 22, 2010 at 4:40 PM, Sandro Tosi <mo...@de...> wrote: > Hello all, > in some time (let's say a couple of months, maybe more) Debian will > enter the "freeze" period, where no new upstream releases are > accepted, in order to prepare the best stable release we can :) > > In the past months I see many changes are accumulated in the SVN but > no new release are done. I don't know if you've already discussed > about releasing mpl, but it would be nice if we can have something > before the freeze, so to have a quite-update mpl in squeeze. > > >From my POV, I'll provide all the support needed, so if there > something I can do just tell me :) Hey Sandro, thanks for the head's up. We would like to get a 1.0 release out and there are two roadbumps we have to navigate first. We'd like to transition our VCS to git, and this impacts our release schedule because of the "get_sample_data" support in the trunk which currently pulls the data from svn but would have to be refactored to pull from hit and we'd like to make the transition before we do a release. Andrew, who is handling the git transition, has been very tied up of late, but thinks he'll have some time in early May. The other issue is my dead OSX build box -- I have access to a 64bit python 2.6 platform for builds for OSX, but currently no other platforms/versions so I have to sink some time into this for a release, though this is not a show stopper as we could do a release with incomplete binary support for OSX. So keep our feet to the fire and make sure we don't fall too far behind so we can get something out before the freeze, hopefully far enough before the freeze that we can get at least one bugfix release out... JDH |
From: Sandro T. <mo...@de...> - 2010-04-22 21:40:45
|
Hello all, in some time (let's say a couple of months, maybe more) Debian will enter the "freeze" period, where no new upstream releases are accepted, in order to prepare the best stable release we can :) In the past months I see many changes are accumulated in the SVN but no new release are done. I don't know if you've already discussed about releasing mpl, but it would be nice if we can have something before the freeze, so to have a quite-update mpl in squeeze. >From my POV, I'll provide all the support needed, so if there something I can do just tell me :) Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
From: Eric F. <ef...@ha...> - 2010-04-22 17:46:10
|
Manuel Metz wrote: > Eric, I've seen the comment "Why is the copy needed?" that you've added > to the axes' hist method. I think this was introduced by me some time > ago. Indeed, I think it is not really needed. If I remember correctly, I > had done the copying to avoid that the input x gets modified (I had bad > experience with that before), but I think we can avoid it? Manuel, It turns out the problem was that 1-D arrays were being converted to 2-D by assigning to the shape attribute. (This is something I often do, but now I will be more cautious about it.) When done on the original input argument, which was returned by "x = np.asarray(x)", this had the side effect of changing that argument. Copying was preventing that. To avoid the copy, one could either make a new view of the argument explicitly, or do it implicitly by using the reshape method instead of assigning to the shape attribute. I chose the second option. Eric |
From: Jeff W. <js...@fa...> - 2010-04-22 05:59:43
|
Eric Firing wrote: > Jeff Whitaker wrote: >> Eric Firing wrote: >>> Jeff, >>> >>> Basemap methods like plot() include a "draw_if_interactive" command, >>> followed by a call to the set_axes_limits() method, which ends with >>> >>> # force draw if in interactive mode. >>> if is_interactive(): >>> figManager = _pylab_helpers.Gcf.get_active() >>> figManager.canvas.draw() >>> >>> It seems to me that you could eliminate all those >>> "draw_if_interactive" blocks from plot etc., and replace the end >>> block of set_axes_limits() with >>> >>> if is_interactive(): >>> import matplotlib.pyplot as plt >>> plt.draw_if_interactive() >>> >>> The advantages would be reduced clutter in the drawing methods, and >>> consistent use of draw_if_interactive. I think the latter would >>> make interactive running of functions and subclasses built on >>> basemap more efficient by reducing redundant draw operations. >>> >>> It also looks like at least most of the operations in >>> set_axes_limits really need to be done only once (although I have >>> not checked this carefully). Instead of repeating them with every >>> call to a plotting method, the basemap instance could keep a list of >>> hashes of axes objects on which the operations have already been >>> run, and use that to prevent duplication. >>> >>> Nothing urgent here--just some ideas that occur to me while working >>> with basemap. If you think any are worth pursuing, and you want me >>> to take a shot at it, let me know. >>> >>> Eric >>> >>> >>> >> Eric: You are right, that could be done much more efficiently. I'm >> stuck in the U.K. waiting for the volcanic dust to clear, so if you >> want to take a shot at it go ahead. >> >> -Jeff >> > > Jeff, > > I made the changes, and removed a few obsolete bits. > > I hope you are cleared to fly soon, if you have not already departed. > > Eric Eric: I'm still here - hope to get out on Sat at the earliest. Thanks for making those changes - I'm sure they will help a lot for interactive use and animations. -Jeff |
From: Eric F. <ef...@ha...> - 2010-04-22 03:02:56
|
Jeff Whitaker wrote: > Eric Firing wrote: >> Jeff, >> >> Basemap methods like plot() include a "draw_if_interactive" command, >> followed by a call to the set_axes_limits() method, which ends with >> >> # force draw if in interactive mode. >> if is_interactive(): >> figManager = _pylab_helpers.Gcf.get_active() >> figManager.canvas.draw() >> >> It seems to me that you could eliminate all those >> "draw_if_interactive" blocks from plot etc., and replace the end block >> of set_axes_limits() with >> >> if is_interactive(): >> import matplotlib.pyplot as plt >> plt.draw_if_interactive() >> >> The advantages would be reduced clutter in the drawing methods, and >> consistent use of draw_if_interactive. I think the latter would make >> interactive running of functions and subclasses built on basemap more >> efficient by reducing redundant draw operations. >> >> It also looks like at least most of the operations in set_axes_limits >> really need to be done only once (although I have not checked this >> carefully). Instead of repeating them with every call to a plotting >> method, the basemap instance could keep a list of hashes of axes >> objects on which the operations have already been run, and use that to >> prevent duplication. >> >> Nothing urgent here--just some ideas that occur to me while working >> with basemap. If you think any are worth pursuing, and you want me to >> take a shot at it, let me know. >> >> Eric >> >> >> > Eric: You are right, that could be done much more efficiently. I'm > stuck in the U.K. waiting for the volcanic dust to clear, so if you want > to take a shot at it go ahead. > > -Jeff > Jeff, I made the changes, and removed a few obsolete bits. I hope you are cleared to fly soon, if you have not already departed. Eric |
From: Eric F. <ef...@ha...> - 2010-04-21 19:43:04
|
Jae-Joon Lee wrote: > Eric, > > Just a minor concern about "locator_params" implicitly calling "autoscale_view". > For example, > > ax1 = subplot(121) > ax1.plot([1,2,3]) > ax1.locator_params("x", nbins=5) > ax1.margins(0.1, tight=True) > > ax2 = subplot(122) > ax2.plot([1,2,3]) > ax2.margins(0.1, tight=True) > ax2.locator_params("x", nbins=5) > > Same commands are applied to each subplot but with different order, > and the results are different. > "ax.2locator_params("x", bnins=5)" implicitly calls > "ax2.autoscale_view(tight=False)", overriding tight=True in margins > call. > > And I think this is a bit confusing. I agree, and I was aware of this problem. It arises from the fact that the "tight" state is not saved, as I think it should be. I will look into fixing that. > > I understand that autoscale_view depends on locator. Still at least > some option to prevent calling "autoscale_view" may be needed? That seems to me like a more complex and confusing solution than saving the "tight" setting, and keeping it until it is explicitly changed by its own setter, by autoscale_view, or by margins. The default for autoscale_view will then be to change "tight" only if the kwarg is provided and is not None. Eric > > Regards, > > -JJ |
From: Jae-Joon L. <lee...@gm...> - 2010-04-21 16:27:24
|
Eric, Just a minor concern about "locator_params" implicitly calling "autoscale_view". For example, ax1 = subplot(121) ax1.plot([1,2,3]) ax1.locator_params("x", nbins=5) ax1.margins(0.1, tight=True) ax2 = subplot(122) ax2.plot([1,2,3]) ax2.margins(0.1, tight=True) ax2.locator_params("x", nbins=5) Same commands are applied to each subplot but with different order, and the results are different. "ax.2locator_params("x", bnins=5)" implicitly calls "ax2.autoscale_view(tight=False)", overriding tight=True in margins call. And I think this is a bit confusing. I understand that autoscale_view depends on locator. Still at least some option to prevent calling "autoscale_view" may be needed? Regards, -JJ |
From: Ryan M. <rm...@gm...> - 2010-04-20 21:54:53
|
On Tue, Apr 20, 2010 at 4:02 PM, John Hunter <jd...@gm...> wrote: > On Tue, Apr 20, 2010 at 3:26 PM, Ryan May <rm...@gm...> wrote: >> Hi, >> >> Continuing the spurt of (independent) development that's been going on >> lately, I committed support for generic timers. There's a base class >> TimerBase that provides the basic API for a timer (start, stop, >> controlling the interval, adding callbacks, etc.), and each GUI >> backend subclasses this to wrap around their toolkit's native timer >> classes. I added a method to each backend's canvas object to >> facilitate creating a backend-specific timer without having to know >> what backend was running. So far, I'm quite happy with how it turned >> out, but I'm curious to hear feedback. Specifically: >> >> 1) Anything missing in the basic TimerBase API? > > You might want to pass the argument as keywords on from the > add_timerr, so you can do > > timer = fig.canvas.new_timer(interval=100, callbacks=[(update_title, ax)]) > > or something like that... Or support a single callback object. I'll look at that. I had been trying to keep the constructor simple, but those extra calls to get it fully initialized aren't in line with the rest of the matplotlib API (been doing too much Qt!). I'll probably make it callbacks=[(func, args, kwargs)], as I think I'm going to go back and add **kwargs anyways. > Speaking of callbacks, do you know about cbook.CallbackRegistry? It > would be nice to standardize on a single interface for handling > callbacks so users and developers can manipulate it directly. We use > this elsewhere in support of mpl event handling and the toolbar so it > is fairly robust. Can you further describe what you see here? I looked at this before, and it seems more valuable if you have a variety of signals. I would have 1. I *could* add a time_event to the list of events in the canvas and use the canvas-level callback registry, but that would actually seem to undo the encapsulation of the timer object. Plus that would only allow one timer attached to a canvas. More importantly, the CallbackRegistry, when processing signals, calls each callback with the same arguments, so there's no way to specify per callback information. Maybe I'm just being dense, so please correct me if I'm missing your vision here. I'd always love to reuse existing code and reduce my "opportunity" to contribute bugs to matplotlib. :) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma |
From: John H. <jd...@gm...> - 2010-04-20 21:03:01
|
On Tue, Apr 20, 2010 at 3:26 PM, Ryan May <rm...@gm...> wrote: > Hi, > > Continuing the spurt of (independent) development that's been going on > lately, I committed support for generic timers. There's a base class > TimerBase that provides the basic API for a timer (start, stop, > controlling the interval, adding callbacks, etc.), and each GUI > backend subclasses this to wrap around their toolkit's native timer > classes. I added a method to each backend's canvas object to > facilitate creating a backend-specific timer without having to know > what backend was running. So far, I'm quite happy with how it turned > out, but I'm curious to hear feedback. Specifically: > > 1) Anything missing in the basic TimerBase API? You might want to pass the argument as keywords on from the add_timerr, so you can do timer = fig.canvas.new_timer(interval=100, callbacks=[(update_title, ax)]) or something like that... Or support a single callback object. Speaking of callbacks, do you know about cbook.CallbackRegistry? It would be nice to standardize on a single interface for handling callbacks so users and developers can manipulate it directly. We use this elsewhere in support of mpl event handling and the toolbar so it is fairly robust. > 2) Is adding new_timer() the canvas a good way to go? I needed a way > to get to backend-specific classes without actually knowing what > backend I'm running (and without calling _pylab_helpers or > pyplot.get_backend()). Figure.canvas seemed to be just about the only > way to go about this. It also makes some sense, because in the case > of Wx and Tk, an actual widget is required to hook up the timer. > > I've added an example in: > examples/event_handling/timers.py > > This just makes a plot with a title that is continually (100 ms) > updating with the current time including milliseconds. It does a good > job of showing the ease with which such interactive updates can be > done now. In fact, this could probably be used to update and simplify > the existing animation demos. However, I'm already finishing up a more > complete animation framework based on this, which should simplify some > of those even further. At that point, I'll probably update the > examples. > Looking forward to seeing it -- thanks! JDH |
From: Ryan M. <rm...@gm...> - 2010-04-20 20:26:43
|
Hi, Continuing the spurt of (independent) development that's been going on lately, I committed support for generic timers. There's a base class TimerBase that provides the basic API for a timer (start, stop, controlling the interval, adding callbacks, etc.), and each GUI backend subclasses this to wrap around their toolkit's native timer classes. I added a method to each backend's canvas object to facilitate creating a backend-specific timer without having to know what backend was running. So far, I'm quite happy with how it turned out, but I'm curious to hear feedback. Specifically: 1) Anything missing in the basic TimerBase API? 2) Is adding new_timer() the canvas a good way to go? I needed a way to get to backend-specific classes without actually knowing what backend I'm running (and without calling _pylab_helpers or pyplot.get_backend()). Figure.canvas seemed to be just about the only way to go about this. It also makes some sense, because in the case of Wx and Tk, an actual widget is required to hook up the timer. I've added an example in: examples/event_handling/timers.py This just makes a plot with a title that is continually (100 ms) updating with the current time including milliseconds. It does a good job of showing the ease with which such interactive updates can be done now. In fact, this could probably be used to update and simplify the existing animation demos. However, I'm already finishing up a more complete animation framework based on this, which should simplify some of those even further. At that point, I'll probably update the examples. I still need to add some documentation to the event handling section of the User's Guide, though this might better belong with a section on animation's that I promise to write once the new framework is checked in. Also, I didn't add a TimerBase implementation for the CocoaAgg backend. I have no idea about that toolkit, so I'd appreciate some help there so we can have an implementation for all of the active GUI toolkits. Any feedback is appreciated. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma |
From: Ryan M. <rm...@gm...> - 2010-04-20 20:07:02
|
On Tue, Apr 20, 2010 at 2:46 PM, Eric Firing <ef...@ha...> wrote: > During the last few days I have added some convenience methods and > pyplot functions. Please review them to see whether names, APIs, or > functionality should be changed. The general motivation is that > formatters and locators are a bit obscure and hidden in the object > hierarchy, so I wanted to make it easier for people to make simple > changes. In addition, in autoscaling, one might want an option that is > almost "tight" but leaves a little margin, so symbols at the edge don't > get sliced off, for example. No comments other than these seem like really good changes to reduce the barrier for the users. Nice work! Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma |
From: Eric F. <ef...@ha...> - 2010-04-20 19:46:30
|
During the last few days I have added some convenience methods and pyplot functions. Please review them to see whether names, APIs, or functionality should be changed. The general motivation is that formatters and locators are a bit obscure and hidden in the object hierarchy, so I wanted to make it easier for people to make simple changes. In addition, in autoscaling, one might want an option that is almost "tight" but leaves a little margin, so symbols at the edge don't get sliced off, for example. At the Axes and pyplot levels, the changes made so far include expanding ticklabel_format() and adding two new methods/functions, locator_params() and margins(). The change to ticklabel_format is the addition of a new kwarg: *useOffset* [True | False | offset]; if True, the offset will be calculated as needed; if False, no offset will be used; if a numeric offset is specified, it will be used. This involved changing the underlying ScalarFormatter to accept a numeric offset as an alternative to calculating it automatically. The docstrings for the new methods are: def locator_params(self, axis='both', tight=False, **kwargs): """ Convenience method for controlling tick locators. Keyword arguments: *axis* ['x' | 'y' | 'both'] Axis on which to operate; default is 'both'. *tight* [True | False] Parameter passed to :meth:`autoscale_view`. Remaining keyword arguments are passed to directly to the :meth:`~matplotlib.ticker.MaxNLocator.set_params` method. Typically one might want to reduce the maximum number of ticks and use tight bounds when plotting small subplots, for example:: ax.locator_params(tight=True, nbins=4) Because the locator is involved in autoscaling, :meth:`autoscale_view` is called automatically after the parameters are changed. This presently works only for the :class:`~matplotlib.ticker.MaxNLocator` used by default on linear axes, but it may be generalized. """ and def margins(self, *args, **kw): """ Convenience method to set or retrieve autoscaling margins. signatures:: margins() returns xmargin, ymargin :: margins(margin, tight=True) margins(xmargin, ymargin, tight=True) margins(x=xmargin, y=ymargin, tight=True) All three forms above set the xmargin and ymargin parameters. All keyword parameters are optional. A single argument specifies both xmargin and ymargin. The *tight* parameter is passed to :meth:`autoscale_view`, which is executed after a margin is changed. Specifying any margin changes only the autoscaling; for example, if *xmargin* is not zero, then *xmargin* times the X data interval will be added to each end of that interval before it is used in autoscaling. """ Eric |