Re: [matplotlib-devel] problems with labeling contour lines in 0.98.3
Hi, I am currently on vacation, so I can´t be of much help - back beginning of next month. It would be useful if you could try the clabel and ginput demo scripts and send images of the resulting figures so that we can determine exactly what things work and don´t work. Thanks, David Mark Bakker <[EMAIL PROTECTED]> ha escrito: > Hello David and the developers list- > > I have had little luck on the mailing list, so sorry for writing you > directly (David may be on vacation). > > I have two problems labeling contour lines in 0.98.3. > > First, when I call clabel, it removes all contours that are not labeled > (because the label doesn't fit on the section of contour, I presume). > This seems like a bug to me (or a really odd feature). It doesn't do this > when inline = False, but I don't think it should do it either when inline = > True > Easy example: > x,y = meshgrid( linspace(-10,10,50), linspace(-10,10,50) ) z = log(x**2 + y**2) cobj = contour(x,y,z) # Note that there are 8 contours levels (11 > contour sections in all) cobj.clabel() > draw() # Now only 5 contours are drawn; the ones in the middle are > removed. > > Second, when using the new manual labeling of contour labels (which is > pretty neat!), how do I end this feature? > The doc string says: right click, or potentially click both mouse buttons > together (which already worries me). > Neither works for me on win32, mpl 0.98.3, TkAgg backend, interactive mode. > Does anybody have a solution? > > Thanks, Mark > This message was sent using IMP, the Internet Messaging Program. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] transform_angles
Hi, I just wanted to send a note saying that I committed an additional method to the Transforms class that transforms angles. The basic idea is to transform an angle at a point to a new angle at the corresponding point in the transformed coordinate system. The included method is generic and should work well for almost any transform provided that the spatial scale isn't too small or too large. Much faster algorithms that would work regardless of spatial scale can be found for particular transforms, particularly affine transforms, but I haven't added these yet. I also added an example script that shows how to use this method to plot text rotated so that it aligns with a line in a figure ( text_rotation_relative_to_line.py ). I initially intended to use this method to give text objects the option to be rotated with respect to the plot coordinate system (as opposed to the screen coordinate system), but I haven't gotten around to finishing this yet. Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] transform_angles
Hi, Actually your question is a good one. One of the reasons I never finished adding an option to text objects to rotate with respect to the plot (is this the correct terminology?), not the screen, is that I wasn't sure of the best way to implement this without making it hopelessly confusing for the user. One way is to add a boolean that tells the text object whether or not the angle is with respect to screen coordinates. In this case, text_obj.get_rotation() would return the angle in whichever coordinate system is the active one based on the boolean, unless an option to get_rotation is specified that would force the angle to the screen coordinate system (this option would then be used by show methods to assure they get the correct angle for plotting on the screen). Similarly, set_rotation would set the angle in the active system. The disadvantage of this approach is that it can be pretty confusing - unless you consult the boolean, you don't know what your angle is measured relative to. Another approach would be to add a ._rotationPlot variable, as well as .get_rotationPlot and .set_rotationPlot text-object methods. In this case, using set_rotation would set the "active" angle to be the screen angle, while using set_rotationPlot would set the "active" angle to be the plot angle. The non-active angle would be set to None and show calls would test for whether or not ._rotation is none, in which case the screen angle would be calculated from the transform. In this case, get_rotation and get_rotationPlot would return angles in the respective system, regardless of which one is "active". What structure would people prefer? Another reason I never finished this is that I got confused by some of the code - there was talk of unitful and unitless rotations and coordinates. Also, I wasn't sure what to do with objects that inherit the text object class - namely, text with a dash. It didn't seem it was worth adding this non-screen rotation functionality to these objects. If anyone can point me in the right direction on these points, I will try to finish a patch for this functionality. Cheers, David On Wed, 2008-11-05 at 10:28 -0500, Michael Droettboom wrote: > Darn clogged e-mail queue! ;) > > I see you've already addressed my question... > > Cheers, > Mike > > David Kaplan wrote: > > Hi, > > > > I just wanted to send a note saying that I committed an additional > > method to the Transforms class that transforms angles. The basic idea > > is to transform an angle at a point to a new angle at the corresponding > > point in the transformed coordinate system. The included method is > > generic and should work well for almost any transform provided that the > > spatial scale isn't too small or too large. Much faster algorithms that > > would work regardless of spatial scale can be found for particular > > transforms, particularly affine transforms, but I haven't added these > > yet. > > > > I also added an example script that shows how to use this method to plot > > text rotated so that it aligns with a line in a figure > > ( text_rotation_relative_to_line.py ). > > > > I initially intended to use this method to give text objects the option > > to be rotated with respect to the plot coordinate system (as opposed to > > the screen coordinate system), but I haven't gotten around to finishing > > this yet. > > > > Cheers, > > David > > > > > > > -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] transform_angles
Hi, On Wed, 2008-11-05 at 11:58 -0500, Michael Droettboom wrote: > What is the argument against? It seems like this would be > straightforward (at least from the outside). But I'm probably > missing > something. More work for diminishing interest Perhaps I am incorrect, but I think this object is only used for legends and axes labels, which probably wouldn't use this feature. If I remember correctly, there was also the problem that the dash had its own rotation angle, which would require a whole other set of corresponding variables and methods to select the coordinate system for the dash I think I saw this and just decided to raise not implemented warnings on attempts to set non-screen coordinate system rotations. Is there a strong desire for adding this feature to text with dash? Cheers, David -- ****** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] transform_angles
Hi, On Wed, 2008-11-05 at 13:28 -0500, Stan West wrote: > Beyond the two options of the screen coordinates and the data > coordinates as the references, I > believe it would be useful to allow other coordinate systems. If I > wanted to diagonally > watermark an entire figure with, say, "DRAFT" or "PRELIMINARY," it > would be convenient to > specify a rotation of +/- 45 degrees relative to the normalized (0-1) > figure coordinates. The > watermark would lie along the diagonal regardless of the aspect ratio. > Likewise, to watermark > only a subplot, one might use the normalized axes coordinates. It > seems especially convenient > if users could accomplish that by passing to the text object one of > the predefined transforms -- > like ax.transData, fig.transFigure, or ax.transAxes -- to specify the > coordinate system for the > rotation. > > Would it be possible to specify the reference system and rotation > angle in a composite transform > using transform machinery such as rotate_deg or rotate_deg_around? > This is an interesting suggestion, but seems like it is (a) a bit out of my league and (b) like it would bring up other issues, such as which coordinate system to use for interpreting the location given to the text function for the text object. The standard way this problem has been dealt with is to create an invisible axes that covers your entire plot and add a text object to that axes. Can this method do the trick for you? Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 62, Issue 6
Hi, I will be on vacation with limited email from July 14 to August 7, 2011. Bonjour, Je serai en conge du 14 juillet jusqu'au 7 aout, 2011. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 62, Issue 7
Hi, I will be on vacation with limited email from July 14 to August 7, 2011. Bonjour, Je serai en conge du 14 juillet jusqu'au 7 aout, 2011. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 62, Issue 8
Hi, I will be on vacation with limited email from July 14 to August 7, 2011. Bonjour, Je serai en conge du 14 juillet jusqu'au 7 aout, 2011. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 62, Issue 9
Hi, I will be on vacation with limited email from July 14 to August 7, 2011. Bonjour, Je serai en conge du 14 juillet jusqu'au 7 aout, 2011. -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 62, Issue 10
Hi, I will be on vacation with limited email from July 14 to August 7, 2011. Bonjour, Je serai en conge du 14 juillet jusqu'au 7 aout, 2011. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 62, Issue 11
Hi, I will be on vacation with limited email from July 14 to August 7, 2011. Bonjour, Je serai en conge du 14 juillet jusqu'au 7 aout, 2011. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 62, Issue 12
Hi, I will be on vacation with limited email from July 14 to August 7, 2011. Bonjour, Je serai en conge du 14 juillet jusqu'au 7 aout, 2011. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 62, Issue 13
Hi, I will be on vacation with limited email from July 14 to August 7, 2011. Bonjour, Je serai en conge du 14 juillet jusqu'au 7 aout, 2011. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 63, Issue 1
Hi, I will be on vacation with limited email from July 14 to August 7, 2011. Bonjour, Je serai en conge du 14 juillet jusqu'au 7 aout, 2011. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, This sounds like a great idea. My trunk version of matplotlib does not have these changes. I presume you would like me to commit them? If so, let me know and it would be great if you could give your code a test using the wx backend afterward. Cheers, David On Thu, 2008-07-17 at 12:13 -0400, Paul Kienzle wrote: > On Thu, Jul 17, 2008 at 09:46:16AM +0200, David M. Kaplan wrote: > > I don't think the blocking code will be that hard to maintain. It > > basically just depends on events, callback functions and time.sleep. If > > those are cross-platform, then it shouldn't be a problem. But only time > > will tell. My ability and desire to test on multiple platforms is > > limited - I use ubuntu/gnome-gtk/linux 100%. > > In addition to your patch you can put start/stop_event_loop > methods into the the canvas. That way backends can specialize > their implementation so they don't need a busy loop while waiting > for the event. > > Then you can replace the termination notice in BlockingInput: > > -self.done = True > +self.fig.canvas.stop_event_loop() > > and move the busy loop to the backend: > > # wait for n clicks > -counter = 0 > -while not self.done: > -self.fig.canvas.flush_events() > -time.sleep(0.01) > - > -# check for a timeout > -counter += 1 > -if timeout > 0 and counter > timeout/0.01: > -print "ginput timeout"; > -break; > +self.fig.canvas.start_event_loop(timeout=timeout) > > > In backend_bases.py I have a generic interactive version > based on sleep: > > class FigureCanvasBase: > ... > def start_event_loop(self, timeout=0): > """ > Run the event loop. > > This call blocks until an event callback triggers > stop_event_loop() or the timeout interval is exceeded. > """ > if timeout == 0: timeout = npy.inf > timestep = 0.01 > counter = 0 > self._looping = True > while self._looping and counter*timestep < timeout: > self.flush_events() > time.sleep(timestep) > counter += 1 > > def stop_event_loop(self): > """ > Stop the event loop. > > The function which started the event loop can now run to completion. > """ > self._looping = False > > > In the wx canvas this is specialized as: > > class FigureCanvasWx(FigureCanvasBase, wx.Panel): > ... > def start_event_loop(self, timeout=0): > """ > Run the event loop. > > This call blocks until an event callback triggers > stop_event_loop() or the timeout interval is exceeded. > """ > root = self.GetTopLevelParent() > bind(root, wx.EVT_CLOSE, self.stop_event_loop) > > id = wx.NewId() > timer = wx.Timer(self, id=id) > if timeout > 0: > timer.Start(timeout*1000, oneShot=True) > bind(self, wx.EVT_TIMER, self.stop_event_loop, id=id) > self._event_loop.Run() > timer.Stop() > > def stop_event_loop(self, event=None): > """ > Stop the event loop. > > The function which started the event loop can now run to completion. > """ > if self._event_loop.IsRunning(): > self._event_loop.Exit() > > # Event binding code changed after version 2.5 > if wx.VERSION_STRING >= '2.5': > def bind(actor,event,action,**kw): > actor.Bind(event,action,**kw) > else: > def bind(actor,event,action,id=None): > if id is not None: > event(actor, id, action) > else: > event(actor,action) > -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] reverting changes to contour.py
Hi, On Sun, 2008-07-20 at 08:09 -1000, Eric Firing wrote: > It sounds like there is time to do it before the release without messing > up the release. Just make sure the backend_drivers.py test suite still > runs OK. If you can add tests (i.e., examples run by backend_drivers) > that exercise the new functionality, that is even better. The > interactive part of the functionality can't be tested in an automated > way, but the rest can, and adding an example is a good way to help users > see how to use it. In any case, go ahead and commit when ready. > I have recommitted my changes to contour.py plus modifications to fix the problems you identified (r5799). I also included a couple of new pylab_examples that test the new interactive (ginput, etc.) and non-interactive (e.g., using a dictionary to specify label format) elements. The non-interactive pylab_example (contour_label_demo) has been integrated into backend_driver.py. This should hopefully help save me from myself. > Yes, the labeling code is difficult, and I have not looked at it in a > long time. If you are interested, please do look at it from the > standpoint of a possible major revision that might make it easier to > understand and easier to enhance. > For the moment, I have tried to add a few comments here and there that explain my understanding of things and identify some problems. One thing that should probably be fixed immediately is that the attribute names in ContourLabeler don't meet the standards in the coding guide (e.g., label_levels instead of clabelLevels) and are hard to understand (e.g., cl could be contourLevels instead of clabelLevels). I would like to fix these, but this may break user's code that depends, e.g., on CS.cl having that name. How much should I worry about this? There are likely few users that directly modify ContourSet properties, but you never know. I think changing these names and adding a few comments would at least pave the way for future improvements. I also have a couple of general questions for the group: 1) ginput currently returns a list of tuples instead of a two-column array of x,y coordinates. I think a numpy array is more intuitive and saves the user having to cast to array. Is there any reason why ginput should not return a numpy array instead of a list of tuples? 2) Can someone explain to me why is_string_like in the cbook doesn't just do isinstance(obj,str)? Is there anything "string like" that won't be caught be this isinstance call? Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] reverting changes to contour.py
Hi, Similar level of question: What is the policy on using scipy in matplotlib? I want to use linear interpolation, and simple_linear_interpolation in the cbook doesn't do what I want. I imagine that we are trying to avoid dependence on scipy. Thanks, David On Mon, 2008-07-21 at 08:42 -0500, John Hunter wrote: > On Mon, Jul 21, 2008 at 7:51 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > > > 2) Can someone explain to me why is_string_like in the cbook doesn't > > just do isinstance(obj,str)? Is there anything "string like" that won't > > be caught be this isinstance call? > > In [65]: s = u'jdh' > > In [66]: isinstance(s, str) > Out[66]: False > > In [67]: isinstance(s, unicode) > Out[67]: True > > So we could check for str or unicode, but a user may be using a custom > string like class from some c++ extension code that is part of a large > in house API. The point is that we don't care if it *is* a string, we > just want it to act like a string > > http://en.wikipedia.org/wiki/Duck_typing -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] is_scalar bug
Hi,
I believe that the cbook.is_scalar function has a bug:
In [19]: cbook.is_scalar('abc')
Out[19]: 1
I believe it should be:
def is_scalar(obj):
'return true if *obj* is not string like and is not iterable'
return not is_string_like(obj) and not iterable(obj)
Cheers,
David
--
**
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] clabel improvements
Hi, Well, I now know more than I ever wanted to about clabel. I decided to improve a bit on the inlining and ended up rewriting it. For automatic label placement, I basically use the existing algorithm for determining label location, but have replaced existing code for determining the angle of rotation and the amount of the contour to take off for inlining with new code. This new code is based on using pixel-space distances along the contour. This allows one to (1) get nice balanced inlining with the same amount of space on either side of the label, and (2) to vary the amount of space you want around the label. It also should deal better with labels located near contour edges and labels covering the entire contour. Along the way, I renamed all ContourLabeler specific attributes to something like .labelAttribute. This makes the namespace cleaner in my mind, but might break existing user code that does things directly with ContourLabeler attributes. I also added a few new functions to cbook. One does simple linear interpolation (in addition to an existing cbook function that is similar but a bit different). Others do things with vector lengths. I also added a function called isvector that is identical to a Matlab function of the same name. If desired, I can move this to mlab.py, but for the moment it is in cbook.py because most of the is? functions are there. On an aside, I noted that mlab.norm uses cut-and-paste documentation from Matlab. Is this wise? I have tested all the changes against the existing pylab_examples and things work fine. Nonetheless, since lots of things have been changed, I haven't committed them for fear of interfering with the release. Instead, I am attaching the patch set. If I get the green light, I will commit these changes. Related: while I am digging around in there, now is probably the moment for me to integrate Paul Kienzle's comments on start/stop_event_loop in FigureCanvasBase, etc. I am not sure there is a consensus on this. I am currently thinking that the best way to integrate this, while minimizing repeated code, is a mixin plus a couple of new classes, FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would inherit the mixin and the base classes without "GUI". Interactive backends would then inherit these. Non-interactive backends would inherit versions that throw errors from FigureBaseCanvas. Complex, but this assures clean inheritance. Thoughts welcome. Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** Index: lib/matplotlib/cbook.py === --- lib/matplotlib/cbook.py (revision 5797) +++ lib/matplotlib/cbook.py (working copy) @@ -287,7 +287,7 @@ def is_scalar(obj): 'return true if *obj* is not string like and is not iterable' -return is_string_like(obj) or not iterable(obj) +return not is_string_like(obj) and not iterable(obj) def is_numlike(obj): 'return true if *obj* looks like a number' @@ -1154,6 +1154,46 @@ return result +def less_simple_linear_interpolation( x, y, xi, extrap=False ): +""" +This function provides simple (but somewhat less so than +simple_linear_interpolation) linear interpolation. This is very +inefficient linear interpolation meant to be used only for a small +number of points in relatively non-intensive use cases. + +Call signature:: + +yi = less_simple_linear_interpolation(x,y,xi) +""" +if is_scalar(xi): xi = [xi] + +x = np.asarray(x) +y = np.asarray(y) +xi = np.asarray(xi) + +s = list(y.shape) +s[0] = len(xi) +yi = np.tile( np.nan, s ) + +for ii,xx in enumerate(xi): +bb = x == xx +if np.any(bb): +jj, = np.nonzero(bb) +yi[ii] = y[jj[0]] +elif xxx[-1]: +if extrap: +yi[ii] = y[-1] +else: +jj, = np.nonzero(x x-xlabel)) & -((yy < y+ylabel) & (yy > y-ylabel))) - -if len(inds) >0: -#if the label happens to be over the beginning of the -#contour, the entire contour is removed, i.e. -#indices to be removed are -#inds= [0,1,2,3,305,306,307] -#should rewrite this in a better way -linds, = np.nonzero(inds[1:]- inds[:-1] != 1) -if inds[0] == 0 and len(linds) != 0: -ii = inds[linds[0]] -lc1 =linecontour[ii+1:inds[ii+1]] -lc2 = [] - -else: -lc1=linecontour[:in
Re: [matplotlib-devel] is_scalar bug
Hi,
Almost:
In [3]: cbook.is_scalar((0,1))
Out[3]: True
That should be an "and" not an "or".
Cheers,
David
On Wed, 2008-07-23 at 08:16 -0500, John Hunter wrote:
> On Wed, Jul 23, 2008 at 4:04 AM, David Kaplan <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I believe that the cbook.is_scalar function has a bug:
> >
> > In [19]: cbook.is_scalar('abc')
> > Out[19]: 1
> >
> > I believe it should be:
> >
> > def is_scalar(obj):
> >'return true if *obj* is not string like and is not iterable'
> >return not is_string_like(obj) and not iterable(obj)
>
> Yep, good catch. I committed this fix to 5822
>
> JDH
--
**
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, I have finally committed a changeset for moving the "event loop" stuff into the backends. I have hopefully found a compromise that will please most. Since this is close to release date, I suggest that everyone who can give it a look (r5831) and if there is any problem, just role the changes back and release with the old code. My compromise was the following: 1) In FigureCanvasBase, create start/stop_event_loop that raise errors. I kept these names instead of wait_start wait_stop because I think things like start_event_loop is used in other programming contexts to denote the same things. In the documentation string, I tried to make it clear that this is not the overall GUI event loop. If people aren't happy, changing is a fairly simple find and replace. 2) In FigureCanvasBase, I also created start/stop_event_loop_default. These do the standard time.sleep thing. start_event_loop_default throws a deprecated warning saying it should be replaced by a gui specific version. Once we have the gui specific versions, I still think we should keep this function around as this code is very simple and straightforward and is likely to work on almost anything. For example, if we ever had a problem with a backend, we could always use this till a fix was found. 3) In cocoagg, fltkagg, gtk, qt, qt4, and tkagg, I implemented fall-through functions for start/stop_event_loop that simply call the default versions. 4) In WX, I used the code submitted by Paul, but was unable to check it because when I tried to use the WX backend, I got an error about no GraphicsContext (below). This looks bad. I am using wxPython: 2.6.3.2. Again, any problem with this, just role the changes back until after the release. Cheers, David Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1035, in _onPaint self.draw(repaint=False) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 903, in draw self.figure.draw(self.renderer) File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 724, in draw if self.frameon: self.patch.draw(renderer) File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 257, in draw gc = renderer.new_gc() File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 360, in new_gc self.gc = GraphicsContextWx(self.bitmap, self) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 457, in __init__ gfx_ctx = wx.GraphicsContext.Create(dc) : 'module' object has no attribute 'GraphicsContext' -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clabel improvements
Hi, I committed the changes to clabel (r5830). For the attribute renaming, I think we can safely rename most of them. In my opinion, the only ones that users might use are .cl, .cl_xy and .cl_cvalues. The clabel function creates these just before finishing from their more appropriately named versions. This should provide enough backward compatibility for a release or two. And yes, isvector is different from iterable. For example: In [81]: cbook.isvector( array([3,4,5,6]).reshape(1,1,1,4) ) Out[81]: True In [82]: cbook.isvector( array([3,4,5,6]).reshape(1,1,2,2) ) Out[82]: False This function is probably more useful in matlab since it has no shape way to distinguish vectors from 2D matrices, but still it doesn't hurt to have it around. Cheers, David On Wed, 2008-07-23 at 08:08 -1000, Eric Firing wrote: > John Hunter wrote: > > On Wed, Jul 23, 2008 at 6:21 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> Well, I now know more than I ever wanted to about clabel. I decided to > >> improve a bit on the inlining and ended up rewriting it. For automatic > >> label placement, I basically use the existing algorithm for determining > >> label location, but have replaced existing code for determining the > >> angle of rotation and the amount of the contour to take off for inlining > >> with new code. This new code is based on using pixel-space distances > >> along the contour. This allows one to (1) get nice balanced inlining > >> with the same amount of space on either side of the label, and (2) to > >> vary the amount of space you want around the label. It also should deal > >> better with labels located near contour edges and labels covering the > >> entire contour. > > It all sounds like much-needed improvement. > > >> > >> Along the way, I renamed all ContourLabeler specific attributes to > >> something like .labelAttribute. This makes the namespace cleaner in my > >> mind, but might break existing user code that does things directly with > >> ContourLabeler attributes. > > > > Eric, do you have any sense of whether people would use this directly? > > I think the probability that anyone is doing this is low, but it would > be nice to ask on the users mailing list. > > > Since this is a point release, I want to minimize API breakage, so at > > least keep the old attrs around for this cycle. Eg, in Axes I > > recently renamed axesPatch to simply patch as follows: > > > > # the patch draws the background of the axes. we want this to > > # be below the other artists; the axesPatch name is deprecated > > self.patch = self.axesPatch = self._gen_axes_patch() > > > > we don't have an easy way to catch deprecated usage w/o some property > > or getattr magic. If you want to add getter properties for the > > deprecated attrs which warn and point to the new, that would be ideal. > > In general, yes, but in this case I think it would be better to go with > your simpler method above, of making duplicate names. It reduces the > code clutter and the chance of introducing last-minute errors. The > mailing list and API_CHANGES can be used to notify users of the upcoming > deprecation. If there is an outcry, indicating wide use of the > attributes, then properties can be introduced later to smooth the > deprecation process. But I predict there will be hardly a peep. > > > > > > >> I also added a few new functions to cbook. One does simple linear > >> interpolation (in addition to an existing cbook function that is similar > >> but a bit different). Others do things with vector lengths. I also > Maybe explain in the docstring or a comment why this version is needed? > >> added a function called isvector that is identical to a Matlab function > Maybe use try/except to return False if the test fails? If the input is > a string, or None, for example? Whether to do this depends on what the > use case is. > >> of the same name. If desired, I can move this to mlab.py, but for the > >> moment it is in cbook.py because most of the is? functions are there. > > > > That's fine. Is this different from "iterable" > > > >> On an aside, I noted that mlab.norm uses cut-and-paste documentation > >> from Matlab. Is this wise? > > > > No, please rewrite the docstring. Some of mlab was borrowed form > > other people's codes, and I was unaware of this. > > norm is one of the things we should not have at all; ours should be > deprecated in favor of numpy.linalg.norm. It would be good
Re: [matplotlib-devel] clabel improvements
Hi, I made the suggested fixes. Comments below: On Thu, 2008-07-24 at 08:38 -0500, John Hunter wrote: > On Thu, Jul 24, 2008 at 7:31 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > > > I committed the changes to clabel (r5830). > > Hey David -- thanks for these fixes. I noticed a couple of things I > want to comment on > > * avoid the ternary operator, as in > > # Figure out label rotation. > rotation,nlc = cs.calc_label_rot_and_inline( > slc, imin, lw, lc if self.inline else [], > self.inline_spacing ) > > since this requires python2.5. I replaced this, and a similar > construct in contour.py, so please make sure I did the right thing > The reason I used this was that I saw the following line in contour.py (line 325): lc = [tuple(l) for l in linecontour] Doesn't this also require 2.5 or is the if different than the for? Should this also be changed? > * avoid needless *args, **kwargs usage. We do this all the time in > pylab and to a lesser extent in axes.py because we are passing the > function call on to another layer. In that case, at least document > the proper signature as the first line in the docstring. But unless > we need it, avoid it, eg in I removed all this arbitrary argument stuff. I was thinking that if we ever invented a better mouse trap, this would let us automatically pass that on to GUI's we haven't written specific functions for yet. But we are unlikely to invent a better mouse trap. > > * Using an empty list in a python kwarg as the default is a gotcha, as in > > def calc_label_rot_and_inline( self, slc, ind, lw, lc=[], spacing=5 ): > > The reason is that if the function mutates the list, this often leads > to unintended consequences as the list is module level and thus shared > between instances and method calls. The standard idiom for mutable > (lists and dicts) keyword args s > > def func(x=None): > if x is None: x = [] > > I have fixed this in contour.py > I don't really understand how this can be a problem, but it probably isn't that important unless you feel like enlightening me. Cheers, David > JDH -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, No, it doesn't appear to work with or without my changes. Also, it looks to me like the following code is now misplaced in backend_wx.py: # Event binding code changed after version 2.5 if wx.VERSION_STRING >= '2.5': def bind(actor,event,action,**kw): actor.Bind(event,action,**kw) else: def bind(actor,event,action,id=None): if id is not None: event(actor, id, action) else: event(actor,action) It now appears after some functions not in the class. Is this OK? Also, I noticed that this defines bind, while elsewhere in the class self.Bind is used. Is this correct? If so, should these other references perhaps take advantage of your abstraction? Cheers, David On Thu, 2008-07-24 at 11:02 -0400, Paul Kienzle wrote: > On Thu, Jul 24, 2008 at 12:12:21PM +0200, David Kaplan wrote: > > 4) In WX, I used the code submitted by Paul, but was unable to check it > > because when I tried to use the WX backend, I got an error about no > > GraphicsContext (below). This looks bad. I am using wxPython: 2.6.3.2. > > Does wx work for you without the change? I suspect not... > > I posted a fix to make the wx backend work for me with > examples/pylab_examples/ginput_demo.py and wx 2.8.3. > > One issue I didn't address properly is what happens when the user > exits by closing the window. Currently it raises an error when > ginput requests draw. > > - Paul -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, I am still getting crashes using the WX backend with the latest SVN. For example: In [1]: figure() Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1092, in _onSize self.draw() File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 892, in draw self.figure.draw(self.renderer) File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 724, in draw if self.frameon: self.patch.draw(renderer) File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 257, in draw gc = renderer.new_gc() File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 366, in new_gc self.gc = GraphicsContextWx(self.bitmap, self) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 463, in __init__ gfx_ctx = wx.GraphicsContext.Create(dc) : 'module' object has no attribute 'GraphicsContext' It appears that this GraphicsContext either isn't in my version of wxPython or isn't initialized properly. Updating to wxPython 2.8 fixed the problem, but I think that breaks other things on my system (like system tools on Ubuntu that I need to use). For now I will just use 2.8, but I may have to revert. Is supporting wx 2.6 a goal? Cheers, David On Thu, 2008-07-24 at 11:55 -0400, Paul Kienzle wrote: > On Thu, Jul 24, 2008 at 05:14:42PM +0200, David Kaplan wrote: > > Hi, > > > > No, it doesn't appear to work with or without my changes. Also, it > > looks to me like the following code is now misplaced in backend_wx.py: > > > > # Event binding code changed after version 2.5 > > if wx.VERSION_STRING >= '2.5': > > def bind(actor,event,action,**kw): > > actor.Bind(event,action,**kw) > > else: > > def bind(actor,event,action,id=None): > > if id is not None: > > event(actor, id, action) > > else: > > event(actor,action) > > > > It now appears after some functions not in the class. Is this OK? > > This code is not part of any class. Anyway, I moved it to the top > of the file. > > > Also, I noticed that this defines bind, while elsewhere in the class > > self.Bind is used. Is this correct? If so, should these other > > references perhaps take advantage of your abstraction? > > I've committed a change so that all functions now use > > bind(self, wx.EVT, callback, id=id) > > rather than > > if wx.VERSION_STRING >= '2.5': > self.Bind(wx.EVT,callback,id=id) > else: > wx.EVT(self, id, callback) > > I'm not set up to test against wx < 2.5, though given its age > and the small user base of matplotlib wx, I'm not sure that > it is relevant anymore. > > > - Paul > -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] doc warnings
Hi, On Thu, 2008-07-24 at 13:08 -0700, [EMAIL PROTECTED] wrote: > WARNING: > /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py:docstring > of matplotlib.axes.Axes.acorr:36: (ERROR/3) Unexpected indentation. > WARNING: :0: (ERROR/3) Unexpected indentation. > WARNING: > /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py:docstring > of > matplotlib.backend_bases.FigureCanvasBase.start_event_loop_default:15: > (WARNING/2) Literal block expected; none found. > I looked at my doc strings and as far as I can tell, they are identical in format to other functions around them. What does this error mean? Cheers, David -- ****** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] differences between twinx and twiny
Hi, I just noticed a bug in twinx/twiny in axes.py. twinx has: ax2 = self.figure.add_axes(self.get_position(True), # sharex=self, frameon=False) while twiny has: ax2 = self.figure.add_axes(self.get_position(True), sharey=self, frameon=False) Therefore twiny will share the y axis, while twinx will not share the x axis. I am not sure what the "desired" behavior is, but one has to be wrong. As the principle use for this is making plots of two curves sharing one axis, but different in the other, I imagine that the twiny behavior is the desired one. If not, then the following doesn't look quite right: from numpy import * from matplotlib.pylab import * x = linspace(0,pi,20) y = sin(x) x2 = x + 0.1 * randn(*x.shape) y2 = 10 + y + 0.1 * randn(*y.shape) a1 = gca() plot(x,y) a2 = twinx() plot(x2,y2, 'o') The pylab_examples/two_scales.py only works because the two curves have identical x values. However, forcing them to share has the undesirable consequence that both x-axes must have the same labels and formatting, producing overlayed labels that are slightly noticeable. I have committed to SVN the change making twinx work like twiny. As an aside, this would not be necessary if there was an easy after the fact way of sharing and unsharing axes (i.e., ax.set_shared_x_axes(ax2)). Cheers, David -- ****** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] auto-rotating text and plotyy
Hi, Attached are two patch sets for you to review and comment on. I am not intending for these to go in this release. One is the beginning of a patch set that lets you choose whether text rotation angle is with respect to screen or axes coordinates. The idea is that you might want text that is properly rotated with respect to some object in a plot (e.g., contours), as opposed to being at some particular angle with respect to screen coordinates. Along the way I added a method to transforms.py that transforms angles at a location. The method included is generic and not at all optimized for simple linear transforms, but it works fairly well. This transform might be useful for other functions (e.g., quiver?). This patch basically works. For example, try the following: plot(arange(5)) th = text(3,3,'abcd',rotation=45,rotationscreen=False) th2 = text(2,2,'ABCD',rotation=45) and then try changing the size of your plot window. 'abcd' doesn't rotate with respect to the line as the window changes size, but 'ABCD' does. There are still some imperfections - the text seems to move above or below the line - I am not sure why this is. Also, I have no idea whether I should be using unitless (self._x,_y) or unitful coordinates (self.convert_(x|y)units) in the transformations. Perhaps someone can enlighten me. It doesn't really matter until one tries non-linear transformations (aka basemap). I also haven't tried to integrate this into TextWithDash. I imagine it can be done, but I wasn't sure it was worth the effort since TextWithDash is mostly used for axes ticks I believe. I am thinking of just forcing rotationscreen to True for this class. Comments? Once these issues are worked out, I would integrate this into contour.py so that windows can be resized without affecting label rotation. The second patch is to pyplot.py to create a plotyy function. This is like a matlab function of the same name that puts two curves with different y ranges on the same x axis. It basically wraps the two_scales.py demo functionality with a bit of extra stuff. I had to use a real hack to change the colors of the y axes. Perhaps someone can think of a better way or perhaps this sub-function should be moved out of plotyy so it can be reused. Also, I couldn't find a way to color the actual y-axis - i.e. the vertical line that is the y-axis. Is there an easy way to do this? Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** Index: lib/matplotlib/text.py === --- lib/matplotlib/text.py (revision 5867) +++ lib/matplotlib/text.py (working copy) @@ -62,6 +62,7 @@ name or fontname string eg, ['Sans' | 'Courier' | 'Helvetica' ...] position (x,y) rotation [ angle in degrees 'vertical' | 'horizontal' +rotationscreen [ True | False ] size or fontsize [ size in points | relative size eg 'smaller', 'x-large' ] style or fontstyle [ 'normal' | 'italic' | 'oblique'] text string @@ -93,6 +94,7 @@ multialignment=None, fontproperties=None, # defaults to FontProperties() rotation=None, + rotationscreen=True, linespacing=None, **kwargs ): @@ -118,6 +120,7 @@ self._horizontalalignment = horizontalalignment self._multialignment = multialignment self._rotation = rotation +self._rotationscreen = rotationscreen self._fontproperties = fontproperties self._bbox = None self._renderer = None @@ -159,6 +162,11 @@ 'return the text angle as float' return get_rotation(self._rotation) # string_or_number -> number +def get_rotationscreen(self): +'''return whether rotation is with respect to screen (True) or +plot coordinate system''' +return self._rotationscreen + def update_from(self, other): 'Copy properties from other to self' Artist.update_from(self, other) @@ -168,6 +176,7 @@ self._horizontalalignment = other._horizontalalignment self._fontproperties = other._fontproperties.copy() self._rotation = other._rotation +self._rotationscreen = other._rotationscreen self._picker = other._picker self._linespacin
Re: [matplotlib-devel] auto-rotating text and plotyy
Hi, Sorry I didn't respond to this immediately - I have had my mind on other things. plotyy is basically a wrapper around twinx that provides a bit of extra/built-in functionality. The idea is that you have two curves with similar x values, but different y that you want to plot together. It plots them both using twinx, but to help with visualisation, it changes the color of each curve and associated axis so that they are easy to distinguish (e.g., left blue, right green). This is also similar to a matlab function of the same name, so it helps us matlab converts out. An example of using this function might be: x = linspace(0,pi,20) y = sin(x) x2 = linspace(0.1,pi-0.1,20) y2 = cos(x2) axs,h1,h2=plotyy(x,y,x2,y2) axs is a list with [ax1,ax2]. As is evident from the code itself, there isn't too much beyond what twinx already does, but this code aids matlab compatibility and also the recursive handle property change is useful. But this recursive code could be extricated to provide a general setp_recursive function that would change a property on an object and all its children (that have that property) if that is of interest. Cheers, David On Fri, 2008-07-25 at 15:00 -0400, Ryan May wrote: > David Kaplan wrote: > > The second patch is to pyplot.py to create a plotyy function. This is > > like a matlab function of the same name that puts two curves with > > different y ranges on the same x axis. It basically wraps the > > two_scales.py demo functionality with a bit of extra stuff. I had to > > use a real hack to change the colors of the y axes. Perhaps someone can > > think of a better way or perhaps this sub-function should be moved out > > of plotyy so it can be reused. Also, I couldn't find a way to color the > > actual y-axis - i.e. the vertical line that is the y-axis. Is there an > > easy way to do this? > > Do you have an example of how to use this (or at least what the results > look like)? I'm having trouble seeing how this differs from twinx. > > Ryan > -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Ginput bug
Hi, I just tried ginput with the latest SVN (gtkagg backend) and it seemed to work fine. I recently have had problems with numpy, scipy, matplotlib and/or wx getting out of sync in terms of binary compatibility. Perhaps a rebuild of one or more of those will fix things for you? Cheers, David On Thu, 2008-09-11 at 11:13 -0700, [EMAIL PROTECTED] wrote: > Message: 2 > Date: Tue, 9 Sep 2008 17:18:05 +0200 > From: " St?fan van der Walt " <[EMAIL PROTECTED]> > Subject: [matplotlib-devel] Ginput bug > To: [EMAIL PROTECTED] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all, > > I noticed that `ginput` no longer works (tested with SVN trunk). Is > this a known problem? > > Kind regards, > St?fan > > --- > PyDeadObjectError Traceback (most recent call > last) > > /Users/stefan/ in () > > /Users/stefan/lib/python2.5/site-packages/matplotlib/pyplot.pyc in > ginput(*args, **kwargs) > 353 If *timeout* is negative, does not timeout. > 354 """ > --> 355 return gcf().ginput(*args, **kwargs) > 356 if Figure.ginput.__doc__ is not None: > 357 ginput.__doc__ = dedent(Figure.ginput.__doc__) > > /Users/stefan/lib/python2.5/site-packages/matplotlib/figure.pyc in > ginput(self, n, timeout, show_clicks) >1039 blocking_mouse_input = BlockingMouseInput(self) >1040 return blocking_mouse_input(n=n, timeout=timeout, > -> 1041 show_clicks=show_clicks) >1042 >1043 def waitforbuttonpress(self, timeout=-1): > > /Users/stefan/lib/python2.5/site-packages/matplotlib/blocking_input.pyc > in __call__(self, n, timeout, show_clicks) > 235 self.clicks = [] > 236 self.marks = [] > --> 237 BlockingInput.__call__(self,n=n,timeout=timeout) > 238 > 239 return self.clicks > > /Users/stefan/lib/python2.5/site-packages/matplotlib/blocking_input.pyc > in __call__(self, n, timeout) > 105 finally: # Run even on exception like ctrl-c > 106 # Disconnect the callbacks > --> 107 self.cleanup() > 108 > 109 # Return the events in this case > > /Users/stefan/lib/python2.5/site-packages/matplotlib/blocking_input.pyc > in cleanup(self) > 222 mark.remove() > 223 self.marks = [] > --> 224 self.fig.canvas.draw() > 225 > 226 # Call base class to remove callbacks > > /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core.pyc > in __getattr__(self, *args) > 14312 if not hasattr(self, "_name"): > 14313 self._name = "[unknown]" > > 14314 raise PyDeadObjectError(self.attrStr % self._name) > 14315 > 14316 def __nonzero__(self): > > PyDeadObjectError: The C++ part of the FigureCanvasWxAgg object has > been deleted, attribute access no longer allowed. > > -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problems with labeling contour lines in 0.98.3
Hi, Yes, I have fixed the problem in my version of matplotlib, but I haven't had the time to look over all of my changes and commit them to SVN. Next week things should get better. If you are really in a hurry, you can try applying the attached patch set to SVN, but better to wait and let me make sure it is all kosher. Cheers, David On Fri, 2008-09-12 at 11:29 +0200, Mark Bakker wrote: > Hello David - > > Sorry for the late reply. I am back from vacation. > > Any luck on solving the problem of the disappearing contour lines when > labelling? It works fine when you don't use the 'inline', but the > picture is of course not as nice, as the labels are not in-line > anymore. Maybe that gives a clue to what goes wrong? > > Thanks, Mark > > On Wed, Sep 3, 2008 at 12:47 PM, David M. Kaplan <[EMAIL PROTECTED]> > wrote: > Hi, > > Back from vacation. The problem with not being able to end > point > selection is easy to fix - allow keyboard clicks to also > select points > and enter to also exit (this is the solution matlab uses). > This is easy > to add and I will try to work on it sometime over the next > couple of > weeks. > > I will try your example sometime soon and see what happens. > It sounds > like the problem has something to do with what happens when > the label > covers the entire contour - currently the contour gets deleted > entirely, > but this seems to be doing something strange in your case. > > Cheers, > David > > > > On Thu, 2008-08-21 at 16:02 +0200, Mark Bakker wrote: > > David - > > > > Enjoy your vacation. > > > > I tried the contour_label_demo and it works fine, but my > problem > > remains. > > > > I suggest you try the example I provided below, and notice > the > > difference between labeling with inline=True and > inline=False. When > > inline=True the contours in the middle part (which don't get > labeled, > > presumably because there isn't enough room) get erased. > > > > I figured out the manual input problem. The trick is that > you require > > to press the middle button to end (I'll do a post to the > user's list). > > Many laptops don't have a middle button. Although > suggestions are > > found on the web that pushing both buttons simultaneously > works, I > > have never seen it work. What you have to do is configure > your > > touchpad such that a corner acts as the middle button. Once > I figured > > that out, I could end manually selecting the labels. Very > nice. If I > > may, I strongly recommend you change the code such that > pushing the > > right button ends the manual input. Is there any reason not > to use the > > right button for that? > > > > I hope you can fix the inline problem. Thanks for all the > other new > > cool features, > > > > Mark > > > > On Tue, Aug 19, 2008 at 4:06 PM, <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I am currently on vacation, so I can´t be of much > help - back > > beginning of next month. It would be useful if > > you could try the clabel and ginput demo scripts and > send > > images of the resulting figures so that we can > determine > > exactly what things work and don´t work. > > > > Thanks, > > David > > > > > > > > Mark Bakker <[EMAIL PROTECTED]> ha escrito: > > > > > > > > Hello David and the developers list- > > > > I have had little luck on the mailing list, > so sorry > > for writing you > > directly (David may be on vacation). > > > > I have two problems labeling contour lines > in 0.98.3. > > > >
Re: [matplotlib-devel] fix to clabel issues plus more
Hi, Sounds fine, though I would note that about half of the code that was in numerical_methods originally came from cbook, not mlab. This code fits equally well in mlab, so I don't have anything against putting it there. Thanks for taking care of this - I have been busy with other things. Cheers, David On Tue, 2008-09-23 at 13:24 -0500, John Hunter wrote: > On Tue, Sep 16, 2008 at 3:26 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I would just undo what I have done rather than putting a lot of moved > > messages all over the place. I personally find the mix of matlab and > > non-matlab stuff in mlab confusing, but I will go with the group > > consensus. > > Since noone else had anything to add here, I moved all the > numerical_methods methods back into mlab until we have a more > comprehensive solution that is friendly to the existing codebase (one > of my apps was just bitten by it...) > > JDH -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 69, Issue 2
Hi, I will be on vacation with limited email from February 18-25, 2012. Bonjour, Je serai en conge du 18 au 25 fevrier, 2012. Thanks, David -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 69, Issue 3
Hi, I will be on vacation with limited email from February 18-25, 2012. Bonjour, Je serai en conge du 18 au 25 fevrier, 2012. Thanks, David -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 69, Issue 4
Hi, I will be on vacation with limited email from February 18-25, 2012. Bonjour, Je serai en conge du 18 au 25 fevrier, 2012. Thanks, David -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 69, Issue 5
Hi, I will be on vacation with limited email from February 18-25, 2012. Bonjour, Je serai en conge du 18 au 25 fevrier, 2012. Thanks, David -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] waitforbuttonpress function addition
Hi, Following Gael Varoquaux's lead on adding a ginput command to matplotlib (nice job!), I added a waitforbuttonpress function to matplotlib. The patch is attached (generate using svn diff from the matplotlib/trunk/matplotlib directory). waitforbuttonpress is a simple function with a matlab equivalent that returns a list of true/false's - true for a keyboard click and false for a mouse click. I use it in matlab regularly as a simple yes/no question (often to decide whether or not to save a figure). The way I have implemented it is by adding an additional class BlockingKeyMouseInput, which is quite similar to BlockingMouseInput, but waits for both key and mouse events. A smarter person than I could probably combine these two classes and make something that would serve both functions. But I am basically new to python and don't feel comfortable. Perhaps someone else could take a look and make improvements/simplifications? The other thing that I have noticed with both ginput and waitforbuttonpress is that if you use ctrl-c to break out of either, then the callback functions remain attached to their respective events (e.g., try ginput(n=-1,timeout=-1,verbose=True) and hit ctrl-c). This probably isn't a huge problem, but it would be nice if there was a way to say "if ctrl-c is pressed, cleanup nicely". Does someone know if that is possible? Cheers, David -- ****** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** -- ****** David M. Kaplan Assistant Researcher UCSC / Institute of Marine Sciences Ocean Sciences 1156 High St. SC, CA 95064 Phone: 831-459-4789 Fax: 831-459-4882 http://pmc.ucsc.edu/~dmk/ ** Index: lib/matplotlib/pyplot.py === --- lib/matplotlib/pyplot.py (revision 5735) +++ lib/matplotlib/pyplot.py (working copy) @@ -335,7 +335,21 @@ if Figure.ginput.__doc__ is not None: ginput.__doc__ = dedent(Figure.ginput.__doc__) +def waitforbuttonpress(*args, **kwargs): +""" +Blocking call to interact with the figure. +This will wait for *n* key or mouse clicks from the user and +return a list containing True's for keyboard clicks and False's +for mouse clicks. + +If *timeout* is negative, does not timeout. +""" +return gcf().waitforbuttonpress(*args, **kwargs) +if Figure.waitforbuttonpress.__doc__ is not None: +waitforbuttonpress.__doc__ = dedent(Figure.waitforbuttonpress.__doc__) + + # Putting things in figures def figtext(*args, **kwargs): Index: lib/matplotlib/figure.py === --- lib/matplotlib/figure.py (revision 5735) +++ lib/matplotlib/figure.py (working copy) @@ -6,6 +6,9 @@ :class:`SubplotParams` control the default spacing of the subplots +:class:`BlockingKeyMouseInput` +creates a callable object to retrieve key or mouse clicks in a blocking way for interactive sessions + :class:`BlockingMouseInput` creates a callable object to retrieve mouse clicks in a blocking way for interactive sessions @@ -118,6 +121,78 @@ setattr(self, s, val) +class BlockingKeyMouseInput(object): +""" +Class that creates a callable object to retrieve key or mouse clicks in a +blocking way. +""" +def __init__(self, fig): +self.fig = fig + + +def on_mouse_click(self, event): +""" +Event handler that will be passed to the current figure to +retrieve clicks. +""" +self.events.append(event) +self.buttons.append(event.button) +self.keyormouse.append(False) + +if len(self.keyormouse) >= self.n: +self.done = True + +def on_key_click(self, event): +""" +Event handler that will be passed to the current figure to +retrieve key presses. +""" +self.events.append(event) +self.keys.append(event.key) +self.keyormouse.append(True) + +if len(self.keyormouse) >= self.n: +self.done = True + +def __call__(self, n=1, timeout=-1 ): +""" +Blocking call to retrieve n key or mouse events +""" +self.done= False +self.keys = [] +self.buttons = [] +self.events = [] +self.keyormouse = [] + +assert isinstance(n, int), "Requires an integer argument" +self.n = n + +
Re: [matplotlib-devel] waitforbuttonpress function addition
Hi, Attached is a new patch to replace the previous one that I sent that does what Gael suggested. It works well and seems fairly efficient to me, but again I am new to python and I could be mistaken about what Gael was suggesting. Basically, I created a base class that does the blocking and collects events of any particular set of types specified by name at initiation. I then created two subclasses that specify exactly which events they deal with and do additional processing beyond just collecting events, one for mouse events and one for mouse+keyboard events. These are then called by ginput and waitforbuttonpress respectively. I also changed my version of waitforbuttonpress so that it precisely matches the functionality of matlab's waitforbuttonpress, with the exception of a timeout option. Comments welcome. Cheers, David On Fri, 2008-07-11 at 16:12 +0200, Gael Varoquaux wrote: > On Fri, Jul 11, 2008 at 03:22:30PM +0200, David M. Kaplan wrote: > > The way I have implemented it is by adding an additional class > > BlockingKeyMouseInput, which is quite similar to BlockingMouseInput, but > > waits for both key and mouse events. A smarter person than I could > > probably combine these two classes and make something that would serve > > both functions. But I am basically new to python and don't feel > > comfortable. Perhaps someone else could take a look and make > > improvements/simplifications? > > The only significantly different lines are the two lines where an > mplconnect is done to register the callback. You could abstract this in a > method and then have a base class and two sub classes for each call: the > blocking from mouse and the blocking from button. > > > The other thing that I have noticed with both ginput and > > waitforbuttonpress is that if you use ctrl-c to break out of either, > > then the callback functions remain attached to their respective events > > (e.g., try ginput(n=-1,timeout=-1,verbose=True) and hit ctrl-c). This > > probably isn't a huge problem, but it would be nice if there was a way > > to say "if ctrl-c is pressed, cleanup nicely". Does someone know if > > that is possible? > > I think this is a good usecase for a try: ... finally: ... . > > I don't have time to do these changes right now, as I am very busy both > with IPython and Mayavi, and will be travelling next two weeks, but you > can have a good at them, and someone else will probably commit your > patch, if you removed the code duplication. > > Cheers, > > Gaël > -- ** David M. Kaplan Assistant Researcher UCSC / Institute of Marine Sciences Ocean Sciences 1156 High St. SC, CA 95064 Phone: 831-459-4789 Fax: 831-459-4882 http://pmc.ucsc.edu/~dmk/ ** Index: lib/matplotlib/pyplot.py === --- lib/matplotlib/pyplot.py (revision 5735) +++ lib/matplotlib/pyplot.py (working copy) @@ -335,7 +335,21 @@ if Figure.ginput.__doc__ is not None: ginput.__doc__ = dedent(Figure.ginput.__doc__) +def waitforbuttonpress(*args, **kwargs): +""" +Blocking call to interact with the figure. +This will wait for *n* key or mouse clicks from the user and +return a list containing True's for keyboard clicks and False's +for mouse clicks. + +If *timeout* is negative, does not timeout. +""" +return gcf().waitforbuttonpress(*args, **kwargs) +if Figure.waitforbuttonpress.__doc__ is not None: +waitforbuttonpress.__doc__ = dedent(Figure.waitforbuttonpress.__doc__) + + # Putting things in figures def figtext(*args, **kwargs): Index: lib/matplotlib/figure.py === --- lib/matplotlib/figure.py (revision 5735) +++ lib/matplotlib/figure.py (working copy) @@ -6,8 +6,16 @@ :class:`SubplotParams` control the default spacing of the subplots +:class:`BlockingInput` +creates a callable object to retrieve events in a blocking way for interactive sessions + +:class:`BlockingKeyMouseInput` +creates a callable object to retrieve key or mouse clicks in a blocking way for interactive sessions. +Note: Subclass of BlockingInput. Used by waitforbuttonpress + :class:`BlockingMouseInput` -creates a callable object to retrieve mouse clicks in a blocking way for interactive sessions +creates a callable object to retrieve mouse clicks in a blocking way for interactive sessions. +Note: Subclass of BlockingInput. Used by ginput :class:`Figure` top level container for all plot elements @@ -118,24 +126,107 @@ setattr(self, s, val) -class BlockingMouseInput(object): +class BlockingInput(object): """ -Class that creates a callable obj
[matplotlib-devel] patch for adding manual label location selection to clabel
Hi,
Attached is a patch (created by issuing svn diff from the
matplotlib/trunk/matplotlib directory) for adding the capability to
manually select the location of contour labels in clabel. Though the
existing algorithm for automatically placing contour labels is very
good, for complex figures with multiple elements it is often desirable
to manually place labels. This functionality is meant to imitate the
matlab functionality of clabel(cs,'manual').
The attached patch includes a modified version of the changes I
previously made to add a "waitforbuttonpress" command to matplotlib as
these changes are a prerequisite for using the added functionality of
clabel (i.e., you shouldn't apply both patches, just this last one).
The changes work as follows:
cs = contour(x,y,z)
cl = clabel(cs,'manual')
(use the third mouse button to finish placing labels, second button to
erase a previously added label)
The patch isn't done - manually selected labels won't be rotated or
inline. There is also a need for general cleaning up and documentation.
I just want to see what people think about the approach before investing
more time. I added this functionality by adding a class
ContourLabelerWithManual that inherits from ContourLabeler and
BlockingMouseInput (the class used by ginput to interactively select
points). ContourSet then inherits from ContourLabelerWithManual instead
of ContourLabeler. If manual is selected, then it enters interactive
mode, if not, then results should be as before.
I also had to move the classes Blocking*Input from figure.py to a
separate file blocking_input.py to avoid circular imports.
Please let me know what you think. Also, I am wondering if the powers
that be would be willing to give me commit access to my own branch of
the matplotlib svn. I don't want to modify the trunk, but for my own
sanity, it would be nice to be able to keep track of my changes
somewhere. If not, I would like to here what other non-commit
developers do to best organize changes.
Thanks,
David
--
**
David M. Kaplan
Assistant Researcher
UCSC / Institute of Marine Sciences
Ocean Sciences
1156 High St.
SC, CA 95064
Phone: 831-459-4789
Fax: 831-459-4882
http://pmc.ucsc.edu/~dmk/
**
Index: lib/matplotlib/pyplot.py
===
--- lib/matplotlib/pyplot.py (revision 5770)
+++ lib/matplotlib/pyplot.py (working copy)
@@ -320,7 +320,21 @@
if Figure.ginput.__doc__ is not None:
ginput.__doc__ = dedent(Figure.ginput.__doc__)
+def waitforbuttonpress(*args, **kwargs):
+"""
+Blocking call to interact with the figure.
+This will wait for *n* key or mouse clicks from the user and
+return a list containing True's for keyboard clicks and False's
+for mouse clicks.
+
+If *timeout* is negative, does not timeout.
+"""
+return gcf().waitforbuttonpress(*args, **kwargs)
+if Figure.waitforbuttonpress.__doc__ is not None:
+waitforbuttonpress.__doc__ = dedent(Figure.waitforbuttonpress.__doc__)
+
+
# Putting things in figures
def figtext(*args, **kwargs):
Index: lib/matplotlib/contour.py
===
--- lib/matplotlib/contour.py (revision 5770)
+++ lib/matplotlib/contour.py (working copy)
@@ -17,6 +17,9 @@
import matplotlib.text as text
import matplotlib.cbook as cbook
+# Import needed for adding manual selection capability to clabel
+from blocking_input import BlockingMouseInput
+
# We can't use a single line collection for contour because a line
# collection can have only a single line style, and we want to be able to have
# dashed negative contours, for example, and solid positive contours.
@@ -128,9 +131,6 @@
self.labels(inline)
-for label in self.cl:
-self.ax.add_artist(label)
-
self.label_list = cbook.silent_list('text.Text', self.cl)
return self.label_list
@@ -335,6 +335,25 @@
return x,y, rotation, dind
+def add_label(self,x,y,rotation,lev,fmt,color,cvalue):
+dx,dy = self.ax.transData.inverted().transform_point((x,y))
+t = text.Text(dx, dy, rotation = rotation,
+ horizontalalignment='center',
+ verticalalignment='center')
+_text = self.get_text(lev,fmt)
+self.set_label_props(t, _text, color)
+self.cl.append(t)
+self.cl_cvalues.append(cvalue)
+
+# Add label to plot here - useful for manual mode label selection
+self.ax.add_artist(t)
+
+def remove_label(self,index=-1):
+'''Defaults to removing last label, but any index can be supplied'''
+self.cl_cvalues.pop(index)
+t = self.cl.pop(index)
+t.remove()
+
def labe
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi all, Thanks for the comments. My sourceforge ID is dmkaplan. Please add me as a developer. I will commit to the trunk and try to not break things, but I am VERY new to python and it is a possibility. If things don't work out, we can always fall back to creating a branch, though I admit that branching and merging in subversion is a pain. And please do notify me about stylistic issues, etc. My contributions are likely to be a bit sporadic and selfish in the sense that I am just adding functionality that I use all the time in matlab. But if everyone did that, it wouldn't be half bad I don't think the blocking code will be that hard to maintain. It basically just depends on events, callback functions and time.sleep. If those are cross-platform, then it shouldn't be a problem. But only time will tell. My ability and desire to test on multiple platforms is limited - I use ubuntu/gnome-gtk/linux 100%. I plan on spending today sprucing up the patch I sent. Unless anyone is against, I will probably commit and notify in stages so that each piece of the puzzle can be considered separately. I have noticed that the current contour labeling code has its idiosyncrasies, including dealing poorly with label resizing and not being very friendly about unbreaking contours (i.e., it is currently not possible to have a true remove method for ContourSet). I don't plan on fixing these (at least until I have a burning desire to resize labels), but think a contribution that allowed people to resize labels and break-unbreak contours would be useful. I plan on compartmentalizing a bit more ContourLabeler so that each bit of functionality is a separate method - this should make integrating a new LabeledLine class a bit easier as we would just need to attach the right method of one to the other. Cheers, David On Wed, 2008-07-16 at 10:10 -1000, Eric Firing wrote: > John Hunter wrote: > > On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote: > > > >> The patch isn't done - manually selected labels won't be rotated or > >> inline. There is also a need for general cleaning up and documentation. > >> I just want to see what people think about the approach before investing > >> more time. I added this functionality by adding a class > >> ContourLabelerWithManual that inherits from ContourLabeler and > >> BlockingMouseInput (the class used by ginput to interactively select > >> points). ContourSet then inherits from ContourLabelerWithManual instead > >> of ContourLabeler. If manual is selected, then it enters interactive > >> mode, if not, then results should be as before. > > > > Hi David, > > > > I think this looks good. I would like to see it finished before > > inclusion (eg rotating the labels inline) but this functionality looks > > very useful. In general, I think it would be nice to have better > > support for easy interaction with figures, eg for annotations. My > > main question is whether blocking input is the best choice. > > Admitedly, most users find it more intuitive to set up blocking input > > rather than using non-blocking input that is terminated by a custom > > button press, key stroke, or command, but I am worried about how > > robust this is across user interfaces and environments, with all the > > attendant problems of GUI threads, mainloops, etc. Gael has done a > > nice job with ginput across backends, but this code is relatively new > > and lightly tested. Basically, someone (probably you and Gael) will > > need to be up to the task of supporting blocking input across user > > interfaces, which probably isn't trivial but maybe I'm overly > > cautious. Anyway, something to think about. > > > >> I also had to move the classes Blocking*Input from figure.py to a > >> separate file blocking_input.py to avoid circular imports. > > > > A minor nit here: when you import blocking_input, you should use > > > > import matplotlib.blocking_input as blocking_input > > > > rather than simply > > > > import blocking_input > > > > as discussed in the coding guide: > > http://matplotlib.sourceforge.net/doc/html/devel/coding_guide.html > > > > On the subject of the docs, we are in the midst of a push to get beter > > documentation for mpl, so anything you can add while working in terms > > of tutorial or faq or whatever on the new code would be welcome. The > > docs are in the doc subdir of the svn trunk. > > > >> Please let me know what you think. Also, I am wondering if the powers > >> that be would be willing to give me commit access to my own branch of >
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, Attached is a new version of the patch that includes ginput, waitforbuttonpress and clabel changes. It is already quite functional, but there are a couple of issues that need improving that I would like to solicit comments on. I explain below after detailing what I have done. I decided to use a slightly different approach for adding manual label placement ability to clabel. I created a class BlockingContourLabeler that inherits from BlockingMouseInput. This code is in blocking_input.py. This class is called by clabel when manual mode is selected and does the labeling by modifying the passed ContourSet object using ContourSet methods. This avoids clouding the ContourSet namespace with BlockingMouseInput variables and methods. Along the way, I generalized BlockingMouseInput so that it makes it very easy to overload methods to create the class for clabel. In general, I think this approach is quite robust and efficient. Label placement and coloring work perfectly. Label rotation and inlining are usable, but not nearly as robust as the automatic versions. The main reason for this is that I can't get my head around how the automatic code (locate_labels and get_label_coords) works and this is preventing me from abstracting that code into something that I can use for non-automatic labeling. It looks to me like it breaks each contour into n chunks, where n is the width of the label in pixels, and then places the label on one of those pieces using the starting and ending points of the chunk to define the label orientation. But this doesn't make much sense to me, so I am hesitant to edit it. Somehow it works and generally looks quite good. Perhaps someone who understands that code can enlighten me. In an ideal world, there would be a general ContourLabeler method that would take the label location and spit out the appropriate rotation, no matter where that label is. If I were to do it, I would transform the contour to pixel space, calculate the pixel distance between points, then use cumsum to find points around the label location that are just greater than labelwidth/2 away along the contour path. These two indices would define the label rotation and would be useful for breaking contours. I can implement this, but I would like to have a better understanding of how the current code works before modifying it. I also made a slight modification to BlockingMouseInput that affects ginput functioning. You can now exit out of ginput at any time using the second mouse button, even if not in infinite mode. This agrees with matlab functionality and can be quite useful if you want to select no more than a certain number of points. Cheers, David On Thu, 2008-07-17 at 09:46 +0200, David M. Kaplan wrote: > Hi all, > > Thanks for the comments. My sourceforge ID is dmkaplan. Please add me > as a developer. I will commit to the trunk and try to not break things, > but I am VERY new to python and it is a possibility. If things don't > work out, we can always fall back to creating a branch, though I admit > that branching and merging in subversion is a pain. And please do > notify me about stylistic issues, etc. > > My contributions are likely to be a bit sporadic and selfish in the > sense that I am just adding functionality that I use all the time in > matlab. But if everyone did that, it wouldn't be half bad > > I don't think the blocking code will be that hard to maintain. It > basically just depends on events, callback functions and time.sleep. If > those are cross-platform, then it shouldn't be a problem. But only time > will tell. My ability and desire to test on multiple platforms is > limited - I use ubuntu/gnome-gtk/linux 100%. > > I plan on spending today sprucing up the patch I sent. Unless anyone is > against, I will probably commit and notify in stages so that each piece > of the puzzle can be considered separately. > > I have noticed that the current contour labeling code has its > idiosyncrasies, including dealing poorly with label resizing and not > being very friendly about unbreaking contours (i.e., it is currently not > possible to have a true remove method for ContourSet). I don't plan on > fixing these (at least until I have a burning desire to resize labels), > but think a contribution that allowed people to resize labels and > break-unbreak contours would be useful. I plan on compartmentalizing a > bit more ContourLabeler so that each bit of functionality is a separate > method - this should make integrating a new LabeledLine class a bit > easier as we would just need to attach the right method of one to the > other. > > Cheers, > David > > On Wed, 2008-07-16 at 10:10 -1000, Eric Firing wrote: > > John Hunter wrote: > > > On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <[EMAIL PR
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, On Thu, 2008-07-17 at 07:47 -0700, [EMAIL PROTECTED] wrote: > Just because the discussion about clabel started, I want to post a > short > snipplet of code that I found useful. It was some sort of hack to get > a > nicer float formating for contours: contour lines represented > confidence > levels of 1, 2.5, 5 and 10 per cent, and I wanted a labeling exactly > as > I have written it here now. So, fmt='%.1f\%%' would have resulted in > 1.0% 2.5% 5.0% ... but I wanted 1% 2.5% 5% ... > > So this was my solution: > > > # some kind of hack: a nicer floating point formating > class nf(float): > def __repr__(self): > str = '%.1f' % (self.__float__(),) > if str[-1]=='0': > return '%.0f' % self.__float__() > else: > return '%.1f' % self.__float__() > > levels = [nf(val) for val in [1.0, 2.5,5.0,10.0] ] > > pylab.clabel(cs, inline=True, fmt='%r \%%') > > > As I said, it's sort of a hack but it works! It might not be worth to > add this to mpl, but probably as an example ...!? > > Manuel Along these lines, I have been thinking that it would be a simple addition to allow fmt to be a dictionary (as an alternative to a string) that matches contour levels with the desired text. This would allow users to label contours with arbitrary strings, which is occasionally useful. If there is interest, I will add this feature. Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi all, I committed to svn (revision 5782) a version of the patch for clabel and waitforbuttonpress. I haven't perfected label rotation yet, but it works at the moment. I also haven't yet followed Paul Kienzle's suggestions (though I think they are a good idea), as I wanted to get a bit more information in relation to one of Gael's comments below. My responses to Gael's comments are mixed in below. Cheers, David On Thu, 2008-07-17 at 17:19 +0200, Gael Varoquaux wrote: > OK, a few comment from quickly glancing at the patch: > > * What happens if twe are in a non interactive terminal, such as > postscript? If this thing is running on a headless server, we don't > want to hang the script because the manual option has been selected. > The current answer is don't do that. In my opinion, all of these functions should probably return an error if not in an interactive terminal or graphical backend. I looked around a bit for a backend neutral way to ask that question, but didn't find anything. isinteractive seems like it should be relevant, but for Agg backend, which doesn't display a graphical window, it was true, so this doesn't seem to fit the bill. I imagine there is a way and one of you can tell me what it is. If so, I will add it in the right place. Another option would be to create a start_event_loop function like Paul suggested and overload that function in those backends that aren't interactive so that it returns an error, but this requires writing one such function for each non-interactive backend. Also, is there any case where an event loop would be useful for a graphically non-interactive backend? If so, this would again mean that this problem would be easier to deal with once in the Blocking* classes. > * Putting this argument in "*args" seems like a bad style (it looks like > matlab). Why don't you use a "label_pos='auto'" keyword argument. This > would be much more robust to the addition of other options, and more in > agreement with the rest of the style of pylab's arguments. > Originally I intended to allow either the v argument or manual, but both ended up hanging around - think of it as a comfort food for matlab users. But you're right and I have now placed it in a keyword argument "manual". > I have to run. I haven't reviewed the patch very well. I think you should > address those two comments and send it again to the list for review. > You'll probably get useful advice and maybe learn more about Python. > > Thanks, > > Gaël -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi,
I just committed some changes to deal with these comments. Responses
below.
Cheers, David
On Thu, 2008-07-17 at 15:16 -0500, John Hunter wrote:
> def __init__(self, fig, eventslist=()):
> self.fig = fig
> assert isinstance(eventslist, tuple), "Requires a tuple of
> event name strings"
> self.eventslist = eventslist
>
> I would probably write a cbook method is_sequence_of_strings and just
> call that since it will be more readable and reusable...
>
Method added to cbook.
> I notice there are some residual print statements in the code -- these
> should be replaced by the verbose handler in matplotlib/__init__.py,
> eg in
>
> if timeout > 0 and counter > timeout/0.01:
> print "Timeout reached";
> break;
>
> and
> if self.verbose:
> print "input %i: %f,%f" % (len(self.clicks),
> event.xdata, event.ydata)
>
> and others in contour.py
>
> You can replace these with
>
> import matplotlib
> matplotlib.verbose.report('something')
>
> and
>
> matplotlib.verbose.report('some nitty gritty details', 'debug')
>
> There should be no prints in mpl.
>
Fixed.
> In contour.py, we have
>
> xmax = np.amax(np.array(linecontour)[:,0])
> xmin = np.amin(np.array(linecontour)[:,0])
> ymax = np.amax(np.array(linecontour)[:,1])
> ymin = np.amin(np.array(linecontour)[:,1])
I noticed these previously, but didn't touch them as this is in the part
of the code that is somewhat mysterious to me. linecontour should
always be an array (at least the linecontours in a Path), so I don't see
much point in forcing it to array. I have removed these and several
other np.array or np.asarray calls that seemed extraneous to me. If
desired, I can include a single np.array call, but I don't think it is
required.
Thanks,
David
--
**
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, On Thu, 2008-07-17 at 16:55 -0400, Paul Kienzle wrote: >FigureCanvasBase: >def start_event_loop(self, ...): >raise NotImplemented >FigureCanvasEventLoopMixin: >def start_event_loop(self, ...): >generic interactive using time.sleep >MyInteractiveBackend(FigureCanvasBase,FigureCanvasEventLoopMixin): >... no start_event_loop since using the generic mixin ... > So just to make sure that I understand this, "MyInteractiveBackend" would be any backend canvas class for whom we want to implement the standard generic mixin. For example, the class FigureCanvasGTK would inherit FigureCanvasEventLoopMixin until we get around to writing something specific for GTK. On the other hand, FigureCanvasWx wouldn't inherit the mixin, but would use the WX specific code you sent yesterday. And FigureCanvasPs wouldn't get anything at all. Am I getting this? If so, then I will go ahead and make the appropriate modifications. Looking at the list of backends, I think it suffices to inherit the mixin for the following backends: cairo, cocoagg, fltkagg?, gdk?, gtk, qt4, qt, tkagg (wx covered with its own code). All other interactive backends should inherit from these. The ones with the question marks I am not really sure about, but will assume true unless told otherwise. I agree with Gael that warning is probably sufficient. This will allow code running in the background to pass over interactive commands such as ginput. This may be better than an immediate error, but could cause problems later in the script when data is expected, but one gets []. Cheers, David -- ****** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi,
My bad - I forgot strings are iterable. This should now be fixed.
Cheers,
David
On Fri, 2008-07-18 at 09:41 -0500, John Hunter wrote:
> On Fri, Jul 18, 2008 at 3:50 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote:
>
> >> I would probably write a cbook method is_sequence_of_strings and just
> >> call that since it will be more readable and reusable...
> >>
> >
> > Method added to cbook.
>
> This method will return true on a string, which is probably not what you want
>
> In [46]: is_sequence_of_strings('jdh was here')
> Out[46]: True
>
> My original example included an additional check on is_string_like(obj).
>
> If you want to optionally support a string as a sequence of strings, I
> think we might need a kwarg to make this explicit.
>
> JDH
--
**
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi,
On Fri, 2008-07-18 at 11:52 -0400, Paul Kienzle wrote:
> If exceptions aren't used, then non-interactive backends should
> return []
>
I think I have changed my mind on this one - an error seems more
appropriate. The real-world use cases for this are (1) someone doesn't
realize they are in a non-user-interface backend and runs ginput and (2)
someone is running in the background a script that contains interactive
elements. In both cases, using these functions is almost certainly an
error on the users side and it is impossible to decide what the user
would like to have returned in this case. If the user really wants
potentially non-interactive run of the code, he could use try, except to
deal with that.
> The current code has another problem in that timeouts will return
> a partial list. This could be handle by raising RuntimeError in
> ginput:
>
> class BlockingInput:
> ...
> def __call__(...):
> ...
> if n > 0 and len(self.clicks) < n:
> raise RuntimeError("Timeout when selecting inputs")
> return self.clicks
>
> If you want to get fancy and return the partial list of clicks,
> this can be done with our own exception class:
>
> --blocking_input.py--
> class InputError(Exception):
> def __init__(self, message, points):
> self.message = message
> self.points = points
> class BlockingInput:
> ...
> def __call__(...):
> ...
> if n > 0 and len(self.clicks) < n:
> raise InputError("Not enough inputs",self.clicks)
> return self.clicks
>
> Importing an extra symbol to catch the error would be ugly. I
> suggest hiding it in the functions that need it instead:
>
> --pyplot.py--
> def ginput(*args, **kwargs):
> ...
> ginput.InputError = matplotlib.blocking_input.InputError
>
> This allows the pylab user to write:
>
> try:
> x = ginput(3,timeout=2)
> except ginput.InputError,e:
> print "ginput only returned %d inputs"%(len(e.points))
>
> - Paul
>
For ginput, there are a number of ways that an impartial list could be
returned and this is often a desired outcome (for example, I often
decide after the fact that I want fewer points than I initially
thought). Perhaps as a compromise we could set the default timeout to
-1 so the user needs to actually choose a timeout (presumably indicating
he/she accepts the consequences). But allowing the user to manually
decide to select fewer points using the second mouse button has proved
quite useful to me and the user would still need to test in this case.
We could warn if not enough points are returned, but an error seems too
much to me.
Cheers,
David
--
**
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, On Fri, 2008-07-18 at 09:24 -0500, John Hunter wrote: > On Fri, Jul 18, 2008 at 4:27 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote: > I'm not a huge fan of mixins. We use them occassionally, eg for > FigureCanvasGtkAgg and their are some good uses for them, but they can > quickly lead to overly complex code so should be avoided where > possible. I find the "deeper hierarchy" approach more appealing here, > but am not sure if it is viable. For example > > class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg) > Actually the case of GTKAgg is an interesting one. I have FigureCanvasGTK inherit the mixin, but this doesn't cascade to GTKAgg because it gets overloaded with the non-user-interface versions from FigureCanvasAgg leading calls to ginput to produce an error. Adding the mixin to the end of GTKAgg's inheritance list didn't work because it seems that python decides that Agg has already overwritten the same mixin included by GTK and ignores the mixin inheritance at the end of the list (this surprised me, but it appears to work that way). One could always force it to use the right ones by adding functions that point to the mixin versions, but this seems less elegant than inheritance. In this and similar cases, is the order of inheritance important? Changing it to (FigureCanvasAgg, FigureCanvasGTK) should fix the problem. > inherits from an interactive and a non-interactive backend, which is a > good example of how quickly multiple mixin inheritance can get tricky. > I think perhaps it is best to create no new classes, put the base > methods in the FigureCanvasBase, make the default behavior > non-interactive, and then overrride them for the GUI backends. Any > problems with this? > Well, yeah. I think this would mean a lot of the same code in many backends. I also like the idea of a deeper hierarchy with a FigureCanvasUserInterface class that inherits FigureCanvasBase but adds functional start/stop_loop_events because it would allow for a simple cbook test for a working user interface: isinstance(mycanvas,FigureCanvasUserInterface) A deeper hierarchy won't help the inheritance problem for GTKAgg though. > Finally, the term "interactive" is a bit confusing and overloaded > here, since "is_interactive" in mpl means someone is working from the > interactive shell and we want to update the figure on every command > (if draw_if_interactive). For clarity, I think we should refer to > this as a "user interface" backend or something like that,. I know in > parts of the backend code we have the designation of interactive > backends, but these variables should probably be renamed to avoid > further confusion, since the other use of interactive is already > enshrined in the frontend api and rc file. > I agree. > JDH -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, On Fri, 2008-07-18 at 15:47 -0400, Paul Kienzle wrote: > The cases I'm thinking about (e.g., select fit range) have a specific > number of points. Other cases (e.g., select shape outline) have an > indefinite number of points. I can't think of case off hand where > I would want e.g., six or fewer points. A good use case of this is a nested zoom functionality - I often use the following code to implement a simple nested zoom to look at areas of figures while flipping through a large series of figures (i.e., in cases where stopping and restarting the code is a bit awkward): while True: x = ginput(2) if len(x)<2: break x.sort(0) axis(x.T.ravel()) Another use is drawing a contour as you click points. I am still thinking that changing the default timeout to -1 is a good idea - this agrees with matlab and forces the naive user to choose fewer points rather than inadvertantly letting it happen. Cheers, David -- ****** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] reverting changes to contour.py
Hi, Sorry about the problems. The labeling code is somewhat difficult to understand and I was using label indices when I should have used level indices (or vice-versa). I have a fix, but want to test it more before committing. Let me know when is a good time to do it so that I don't mess up a release. Cheers, David On Sat, 2008-07-19 at 19:30 -0700, [EMAIL PROTECTED] wrote: > David, > > I am reverting your changes to contour.py; that is, I am taking it > back > to 5689. The problem is that running contour_demo.py, below, fails. > Some index accounting somewhere is getting fouled up. I don't have > time > to investigate. > > When you have it straightened out you can put the changes back, so > this > is just a brief setback. > > We might want to consider, however, whether such extensive changes > should be made immediately *before* a "bugfix" release. I think John > is > trying to get one out. I am already a little nervous about other > recent > and impending changes in this context. (Your idea of a branch was a > good one in concept, but maybe a pain and more trouble than it is > worth > with svn. Too bad we aren't using something nice like Mercurial. > Now, > that comment should push a few buttons.) > > Eric > -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] doc warnings
Hi, On Fri, 2008-07-25 at 12:43 -0500, John Hunter wrote: > Also, I would rather not put the geometry functions in cbook, eg > distances_along_curve and path_length and friends. Perhaps we should > have some sort of geometry module where all these things live (there > are some in mlab as well) but barring that I would rather have > math/geometry stuff in mlab and general purpose helpers in cbook. > Let's move all those before the release so we don't have to worry > about API breakage later. > I started looking at this reorganization, but it seems to me that mlab already has a number of functions that don't seem to have much to do with its initial purpose - matlab compatibility. This was pretty confusing for me when I initially started using matplotlib as the mlab namespace was a mix of familiar and unfamiliar. I decided instead to group several functions into a "numerical_methods" module that includes most of my new cbook functions as well as some linear interpolation and polygon stuff from mlab. I moved isvector to mlab since this really is an imitation of a matlab function of the same name. I have propagated these changes through to other functions in matplotlib that use them and added remarks in CHANGELOG and API_CHANGES. As these changes may be debatable, I haven't committed them. Instead, I am attaching a patchset. I probably won't check email this weekend, so I will let the powers that be decide what to do with this. Along the way, I noticed these is some duplication in the examples directory between pylab_examples and mpl_examples. Cheers, David > JDH -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** Index: CHANGELOG === --- CHANGELOG (revision 5885) +++ CHANGELOG (working copy) @@ -1,3 +1,7 @@ +2008-07-26 Reorganized cbook and mlab methods related to numerical + calculations that have little to do with the goals of those two + modules into a separate module numerical_methods.py - DMK + 2008-07-24 Deprecated (raise NotImplementedError) all the mlab2 functions from matplotlib.mlab out of concern that some of them were not clean room implementations. JDH Index: lib/matplotlib/cbook.py === --- lib/matplotlib/cbook.py (revision 5885) +++ lib/matplotlib/cbook.py (working copy) @@ -1156,47 +1156,6 @@ return result -def less_simple_linear_interpolation( x, y, xi, extrap=False ): -""" -This function provides simple (but somewhat less so than -simple_linear_interpolation) linear interpolation. -simple_linear_interpolation will give a list of point between a -start and an end, while this does true linear interpolation at an -arbitrary set of points. - -This is very inefficient linear interpolation meant to be used -only for a small number of points in relatively non-intensive use -cases. -""" -if is_scalar(xi): xi = [xi] - -x = np.asarray(x) -y = np.asarray(y) -xi = np.asarray(xi) - -s = list(y.shape) -s[0] = len(xi) -yi = np.tile( np.nan, s ) - -for ii,xx in enumerate(xi): -bb = x == xx -if np.any(bb): -jj, = np.nonzero(bb) -yi[ii] = y[jj[0]] -elif xxx[-1]: -if extrap: -yi[ii] = y[-1] -else: -jj, = np.nonzero(xx[-1]: +if extrap: +yi[ii] = y[-1] +else: +jj, = np.nonzero(x x[-1], the routine tries a +extrapolation. The relevance of the data obtained from this, of +course, questionable... + +original implementation by Halldor Bjornsson, Icelandic +Meteorolocial Office, March 2006 halldor at vedur.is + +completely reworked and optimized for Python by Norbert Nemec, +Institute of Theoretical Physics, University or Regensburg, April +2006 Norbert.Nemec at physik.uni-regensburg.de + +""" + +# Cast key variables as float. +x=np.asarray(x, np.float_) +y=np.asarray(y, np.float_) +assert x.shape == y.shape +N=len(y) + +if yp is None: +yp = slopes(x,y) +else: +yp=np.asarray(yp, np.float_) + +xi=np.asarray(xi, np.float_) +yi=np.zeros(xi.shape, np.float_) + +# calculate linear slopes +dx = x[1:] - x[:-1] +dy = y[1:] - y[:-1] +s = dy/dx #note length of s is N-1 so last element is #N-2 + +# find the segment each xi is in +# this line actually is the key to the efficiency of this implementation +idx = n
[matplotlib-devel] duplicate functions?
Hi, Quick question: I have noticed that there are functions in cbook that have identical or near identical versions in numpy - unique, is_scalar (isscalar), iterable, Is this intentional? Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problems with labeling contour lines in 0.98.3
Hi, Back from vacation. The problem with not being able to end point selection is easy to fix - allow keyboard clicks to also select points and enter to also exit (this is the solution matlab uses). This is easy to add and I will try to work on it sometime over the next couple of weeks. I will try your example sometime soon and see what happens. It sounds like the problem has something to do with what happens when the label covers the entire contour - currently the contour gets deleted entirely, but this seems to be doing something strange in your case. Cheers, David On Thu, 2008-08-21 at 16:02 +0200, Mark Bakker wrote: > David - > > Enjoy your vacation. > > I tried the contour_label_demo and it works fine, but my problem > remains. > > I suggest you try the example I provided below, and notice the > difference between labeling with inline=True and inline=False. When > inline=True the contours in the middle part (which don't get labeled, > presumably because there isn't enough room) get erased. > > I figured out the manual input problem. The trick is that you require > to press the middle button to end (I'll do a post to the user's list). > Many laptops don't have a middle button. Although suggestions are > found on the web that pushing both buttons simultaneously works, I > have never seen it work. What you have to do is configure your > touchpad such that a corner acts as the middle button. Once I figured > that out, I could end manually selecting the labels. Very nice. If I > may, I strongly recommend you change the code such that pushing the > right button ends the manual input. Is there any reason not to use the > right button for that? > > I hope you can fix the inline problem. Thanks for all the other new > cool features, > > Mark > > On Tue, Aug 19, 2008 at 4:06 PM, <[EMAIL PROTECTED]> wrote: > Hi, > > I am currently on vacation, so I can´t be of much help - back > beginning of next month. It would be useful if > you could try the clabel and ginput demo scripts and send > images of the resulting figures so that we can determine > exactly what things work and don´t work. > > Thanks, > David > > > > Mark Bakker <[EMAIL PROTECTED]> ha escrito: > > > > Hello David and the developers list- > > I have had little luck on the mailing list, so sorry > for writing you > directly (David may be on vacation). > > I have two problems labeling contour lines in 0.98.3. > > First, when I call clabel, it removes all contours > that are not labeled > (because the label doesn't fit on the section of > contour, I presume). > This seems like a bug to me (or a really odd feature). > It doesn't do this > when inline = False, but I don't think it should do it > either when inline = > True > Easy example: > > x,y = > meshgrid( linspace(-10,10,50), > linspace(-10,10,50) ) > z = log(x**2 + y**2) > cobj = contour(x,y,z) # Note > that there are 8 contours > levels (11 > contour sections in all) > cobj.clabel() > > draw() # Now only 5 contours > are drawn; the ones in the > middle are > removed. > > Second, when using the new manual labeling of contour > labels (which is > pretty neat!), how do I end this feature? > The doc string says: right click, or potentially click > both mouse buttons > together (which already worries me). > Neither works for me on win32, mpl 0.98.3, TkAgg > backend, interactive mode. > Does anybody have a solution? > > Thanks, Mark > > > > > > --
[matplotlib-devel] error when plotting with point markers in latest SVN
Hi, I am getting errors any time I try to plot with markers for the points (using the GTKAgg backend). My SVN repo copy has a lot of my own changes in it, but I don't think these errors are associated with those changes. Can someone confirm this is a bug? Example below. Thanks, David In [16]: clf(),plot([1,2],[1,2],'--') Out[16]: (None, []) In [17]: clf(),plot([1,2],[1,2],'--o') Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", line 333, in expose_event self._render_figure(self._pixmap, w, h) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", line 75, in _render_figure FigureCanvasAgg.draw(self) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 261, in draw self.figure.draw(self.renderer) File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 759, in draw for a in self.axes: a.draw(renderer) File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1525, in draw a.draw(renderer) File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 439, in draw markerFunc(renderer, gc, tpath, affine.frozen()) File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 752, in _draw_circle rgbFace) : Codes array is wrong length Out[17]: (None, []) -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] error when plotting with point markers in latest SVN
Hi, I apologize for the false alarm - the problem seems to have been somehow due to my versions of numpy, scipy and matplotlib getting out of sync. It now appears to be fixed. Cheers, David On Mon, 2008-09-08 at 13:04 -0400, Jae-Joon Lee wrote: > > > > I am getting errors any time I try to plot with markers for the points > > (using the GTKAgg backend). My SVN repo copy has a lot of my own > > changes in it, but I don't think these errors are associated with those > > changes. Can someone confirm this is a bug? Example below. > > I also don't see that error. > Is your matplotlib code up to date? > There has been a bug which might be related with yours (at least the > raised Exception is same), but this has been fixed in the current SVN. > > http://sourceforge.net/mailarchive/forum.php?thread_name=6e8d907b0808181233g4657bd05ybbc2fe8caf8fe68e%40mail.gmail.com&forum_name=matplotlib-devel > > -JJ > > > > > > > > > > > Thanks, > > David > > > > In [16]: clf(),plot([1,2],[1,2],'--') > > Out[16]: (None, []) > > > > In [17]: clf(),plot([1,2],[1,2],'--o') > > > > Traceback (most recent call last): > > File > > "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", > > line 333, in expose_event > >self._render_figure(self._pixmap, w, h) > > File > > "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", > > line 75, in _render_figure > >FigureCanvasAgg.draw(self) > > File > > "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", > > line 261, in draw > >self.figure.draw(self.renderer) > > File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line > > 759, in draw > >for a in self.axes: a.draw(renderer) > > File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1525, > > in draw > >a.draw(renderer) > > File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 439, > > in draw > >markerFunc(renderer, gc, tpath, affine.frozen()) > > File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 752, > > in _draw_circle > >rgbFace) > > : Codes array is wrong length > > > > Out[17]: (None, []) > > > > -- > > ** > > David M. Kaplan > > Charge de Recherche 1 > > Institut de Recherche pour le Developpement > > Centre de Recherche Halieutique Mediterraneenne et Tropicale > > av. Jean Monnet > > B.P. 171 > > 34203 Sete cedex > > France > > > > Phone: +33 (0)4 99 57 32 27 > > Fax: +33 (0)4 99 57 32 95 > > http://www.ur097.ird.fr/team/dkaplan/index.html > > ** > > > > > > > > - > > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > > Build the coolest Linux based applications with Moblin SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > ___ > > Matplotlib-devel mailing list > > Matplotlib-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] fix to clabel issues plus more
Hi, Just wanted to note that I committed to SVN a fix to the clabel/ginput issues previously identified, plus a few more changes I have worked on along the way. clabel and ginput now allow you to use the keyboard for selecting, erasing and ending point input. I also moved a bunch of functions having to do with numerics and geometry from cbook and mlab into a separate file called numerical_methods.py as was discussed a while back. This is fairly easy to undo if a problem, but this seems logical to me. Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] fix to clabel issues plus more
Hi, I would just undo what I have done rather than putting a lot of moved messages all over the place. I personally find the mix of matlab and non-matlab stuff in mlab confusing, but I will go with the group consensus. Cheers, David On Sun, 2008-09-14 at 12:08 -0500, John Hunter wrote: > On Sun, Sep 14, 2008 at 10:44 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote: > > > I also moved a bunch of functions having to do with numerics and > > geometry from cbook and mlab into a separate file called > > numerical_methods.py as was discussed a while back. This is fairly easy > > to undo if a problem, but this seems logical to me. > > Hi David, I don't mind a reorganization, but there are a few things > about this that I think we can improve upon. In this case, I think a > partial solution, moving some of the functions but not others with no > clear reason why some remain and some were moved, may be worse than > doing nothing since people won't know where to look when they need > something. I would be in favor of either putting everything in mlab, > which is my preference, or moving everything but the matlab > compatibility functions. One other possibility which we raised last > time is to put all the geometry functions in one place, eg in a "geom" > or "geometry" module and leave everything else in mlab. > > Two other points > > * the name numerical_methods is too long, let's find something nice and > short > > * everything that gets moved should have the original function left > in place with a deprecation warning that points to the replcaement in > the help string and in the function call. The old function can just > forward the call onto the new function, but it is a bit tough for > regular users who may be relying on a function to just see it gone > with no idea where to look for the replacement. Also, include a mpl > version or date for any function deprecated so that we can know later > when to remove it, eg after one or two release cycles. As it is, we > have lots of deprecated functions with no obvious date or version > stamp when they were deprecated. > > Anyway, thanks for the fixes and I hope these suggestions aren't too onerous. > > JDH -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
