[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 [email protected] 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 [email protected] 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
[email protected]
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 [email protected] 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
[email protected]
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
[email protected]
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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 > > [email protected] > > 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 [email protected] 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 [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
