[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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
[email protected]
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[:inds[0]] -lc2= linecontour[inds[-1]+1:] - -else: -lc1=lineco
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
[email protected]
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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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._linespacing = other._linespacing @@ -207,8 +216,18 @@ height = ymax-ymin xmax = xmin + width +# Get proper rotation angle +angle = self.get_rotation() +if not self.get_rotationscreen(): +
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 [email protected] 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 [email protected] 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. > > > > 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 > >
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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
