matplotlib-devel Mailing List for matplotlib (Page 14)

On Thursday 17 July 2008 10:59:23 am John Hunter wrote:
> On Thu, Jul 17, 2008 at 2:46 AM, David M. Kaplan <dm...@uc...> wrote:
> > Thanks for the comments.  My sourceforge ID is dmkaplan.  Please add me
>
> Hi David -- I've added you as a developer so you should be able to
> commit now.  The developer's guide is here:
>
>   http://matplotlib.sourceforge.net/doc/html/index.html
>
> Welcome aboard!

Welcome aboard David!

On Thu, Jul 17, 2008 at 2:46 AM, David M. Kaplan <dm...@uc...> wrote:

> Thanks for the comments.  My sourceforge ID is dmkaplan.  Please add me

Hi David -- I've added you as a developer so you should be able to
commit now.  The developer's guide is here:

  http://matplotlib.sourceforge.net/doc/html/index.html

Welcome aboard!

JDH

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 <dm...@uc...> 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
> > >> 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.
> > > 
> > > If you send me your sf id, I will add you to the developer list.  I
> > > don't mind you committing to the trunk unless you are afraid your
> > > changes will break code.  I am not a huge fan of having a lot of
> > > branches.
> > > 
> > > Thanks for the submission -- I await more informed commentary from
> > > those who actually use contouring....
> > 
> > I agree with adding the functionality provided it can be done in a 
> > robust and maintainable way; I have never looked into the arcane aspects 
> > of gui interaction across backends.
> > 
> > Unless it got fixed as part of the transforms re-write, there are 
> > problems even with the existing contour labeling, in that it does not 
> > (or did not) handle resizes well.  Among the many things I have thought 
> > of but not gotten to is the idea that there should be a LabeledLine 
> > class to handle this outside of contour.py.  The idea is that in 
> > addition to the ordinary line path, it would include a list of labels 
> > and positions (not sure what the right way to specify the positions is), 
> > and the class would handle breaking the path and inserting the correctly 
> > rotated text.
> > 
> > Eric
> > 
> > 
> > > 
> > > JDH
> > > 
> > > -------------------------------------------------------------------------
> > > 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
> > > Mat...@li...
> > > 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
**********************************
-- 
**********************************
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
**********************************

On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> wrote:
> Hi All,
> I'd like to "resubmit" the request below: any new version to be
> released soon? in the process to generate the doc in Debian, something
> got fixed upstream, so a new release would be really helpful to have
> 0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with
> strange chars in it).

I think we could do a 0.98.3 release.  There have been several bugs
fixed.  Could you do me a favor and check svn r5722 and see if it
meets all your requirements for  debian before we actually do the
release?

Thanks,
JDH

Hi All,
I'd like to "resubmit" the request below: any new version to be
released soon? in the process to generate the doc in Debian, something
got fixed upstream, so a new release would be really helpful to have
0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with
strange chars in it).

I'm lookgin forward to heard back from you soon.

Thanks in advance,
Sandro

On Wed, Jul 2, 2008 at 13:46, Sandro Tosi <mat...@gm...> wrote:
> Hi guys,
> in Debian we finally find a nice way to let the documentation be
> compiled at package build-time so we are ready for a "real" new
> release of matplotlib (more that the source-only you kindly provided
> me last week), so when you're ready.... :)
>
> For sure, I won't upload a new one in the next 2/3 days or so, because
> I want to let 0.98.1 transit from unstable to testing (the Debian
> staging area used to release lenny), so from the weekend on I'd be
> glad to upgrade matplotlib and bother the release team to include it
> in the next release :)
>
> Thank a lot for the great support you gave/giving me,
> Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

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 <dm...@uc...> 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
> >> 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.
> > 
> > If you send me your sf id, I will add you to the developer list.  I
> > don't mind you committing to the trunk unless you are afraid your
> > changes will break code.  I am not a huge fan of having a lot of
> > branches.
> > 
> > Thanks for the submission -- I await more informed commentary from
> > those who actually use contouring....
> 
> I agree with adding the functionality provided it can be done in a 
> robust and maintainable way; I have never looked into the arcane aspects 
> of gui interaction across backends.
> 
> Unless it got fixed as part of the transforms re-write, there are 
> problems even with the existing contour labeling, in that it does not 
> (or did not) handle resizes well.  Among the many things I have thought 
> of but not gotten to is the idea that there should be a LabeledLine 
> class to handle this outside of contour.py.  The idea is that in 
> addition to the ordinary line path, it would include a list of labels 
> and positions (not sure what the right way to specify the positions is), 
> and the class would handle breaking the path and inserting the correctly 
> rotated text.
> 
> Eric
> 
> 
> > 
> > JDH
> > 
> > -------------------------------------------------------------------------
> > 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
> > Mat...@li...
> > 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
**********************************

John Hunter wrote:
> On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dm...@uc...> wrote:
> 
> Thanks for the submission -- I await more informed commentary from
> those who actually use contouring....
> 


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

John Hunter wrote:
> On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dm...@uc...> 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
>> 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.
> 
> If you send me your sf id, I will add you to the developer list.  I
> don't mind you committing to the trunk unless you are afraid your
> changes will break code.  I am not a huge fan of having a lot of
> branches.
> 
> Thanks for the submission -- I await more informed commentary from
> those who actually use contouring....

I agree with adding the functionality provided it can be done in a 
robust and maintainable way; I have never looked into the arcane aspects 
of gui interaction across backends.

Unless it got fixed as part of the transforms re-write, there are 
problems even with the existing contour labeling, in that it does not 
(or did not) handle resizes well.  Among the many things I have thought 
of but not gotten to is the idea that there should be a LabeledLine 
class to handle this outside of contour.py.  The idea is that in 
addition to the ordinary line path, it would include a list of labels 
and positions (not sure what the right way to specify the positions is), 
and the class would handle breaking the path and inserting the correctly 
rotated text.

Eric


> 
> JDH
> 
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John Hunter wrote:
> On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dm...@uc...> wrote:
>   
>> 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.
>>     
>
> If you send me your sf id, I will add you to the developer list.  I
> don't mind you committing to the trunk unless you are afraid your
> changes will break code.  I am not a huge fan of having a lot of
> branches.
>   
I agree with John -- you should just get developer access and be careful 
not to break things (easier said than done, especially for yours truly).

For future reference, though, I've been using git-svn (which lets you 
use git for a local repository that tracks a remote SVN repository) on a 
hobby-time project and have found it pretty useful for keeping my own 
local history without disturbing (or even having write access to) the 
central SVN repository.  Of course, moving from svn to git requires 
retraining the fingers a little bit, but it's not too bad.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Ryan May wrote:
> Hi,
>
> I've got (what seems to me) a nice clean, self-contained 
> implementation of wind barbs plots.  I'd like to see if I can get this 
> into matplotlib, as it would be very useful to the meteorology 
> community.  I've borrowed heavily from Quiver for rounding out rough 
> edges (like multiple calling signatures) as for templates for 
> documentation.  The base implementation, though, seems much simpler 
> (thanks to Mike's transforms) and is based more on scatter.
>
> Right now it monkey-patches Axes so that it can be a stand-alone file. 
> Just running the file should give a good example of the expected output.
>
> My only concern up front is if a new axes method is appropriate, since 
> this is somewhat domain specific.  But I'd like to at least get the 
> new Collections class included, since otherwise, I have no idea how to 
> get this distributed to the community at large.
>
> I welcome any comments/criticism to help improve this.
>
> Ryan
>
Ryan:  This looks great!  I fixed one typo (the "length" keyword was 
mis-identified as "scale" in the docstring) and replace your example 
with an adaption of the quiver_demo.py basemap example.

I noticed that ticks on the barbs are so close that they are hard to 
discern unless the linewidth is reduced.  I wonder if the spacing of the 
ticks  could be added as a keyword, perhaps as a fraction of the wind 
barb length?

This will be a wonderful addition to matplotlib.  Thanks!

-Jeff

P.S.  eagerly awaiting your Skew-T implementation ....


-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dm...@uc...> 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
> 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.

If you send me your sf id, I will add you to the developer list.  I
don't mind you committing to the trunk unless you are afraid your
changes will break code.  I am not a huge fan of having a lot of
branches.

Thanks for the submission -- I await more informed commentary from
those who actually use contouring....

JDH

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/
**********************************

John Hunter wrote:
> On Tue, Jul 15, 2008 at 5:37 PM, Ryan May <rm...@gm...> wrote:
>
>   
> The 2nd alternative, which I haven't
> explored, is to set the edgecolor equal to the facecolor and support
> colormapping of the edgecolors.
>   
FWIW, pcolor and pcolormesh have also needed this functionality, and 
they do so in a somewhat hackish way.  It would be nice (if barbs goes 
this way) to move that up into the Collections class and reuse it 
everywhere that needs it.

Mike
>
>   

On Tue, Jul 15, 2008 at 5:37 PM, Ryan May <rm...@gm...> wrote:

> I welcome any comments/criticism to help improve this.

Hey Ryan,

I have looked at this code briefly and have a few minor comments.  I
think Eric, who did the bulk of the current quiver implementation, and
as an oceanographer is in a field much closer to yours than mine, will
provide more useful feedback and should ultimately handle the patch
submission.

My first comment is that the code looks very good -- it is well
thought out and commented, and t is definitely suitable for inclusion
in the main line.  Certainly the Barbs class can live in the
collections module.  You note in the driver code that you are worried
about pollution of the axes namespace by including a domain specific
method, and this is a reasonable worry, but the axes namespace is
currently so polluted with plotting methods that it is a small worry.
I think it would be fine for you to rework your code into a patch
which provides the Barbs collection in matplotlib.collections, an Axes
method, and a pyplot interface function (with a pylab module level
docstring entry).  The overloading of the Axes namespace is not ideal,
but it's what we've got.

My second comment has to do with your comment at the end of the example:

     #Showing colormapping with uniform grid. Unfortunately, only the flags
     #on barbs get colormapped this way.

On a cursory read of the code, it looks like you have implemented
everything as a single poly collection, and the reason the flags only
get colored is that the varicolored is black.  It seems like there are
two solutions: write your class as a combination of poly collection
(for the flags) and line collection (for the barbs) and colormap both
(there are some line collection colormapping examples in the examples
subdir courtesy of Eric).  The 2nd alternative, which I haven't
explored, is to set the edgecolor equal to the facecolor and support
colormapping of the edgecolors.

Overall this is very promising, and I wish you the best trying to make
mpl serviceble to the meteorology community.  Jeff Whitaker has done a
phenomenal job with basemap providing extensions for those needing
cartographic projections as a toolkit.  Depending on how far you want
to go with meteorological support, we can include the changes in the
mainline or fold them into a toolkit if they become hyper-specialized.

JDH

Bonjour,

C'est dangeureux dans m'envoyer un email dans ma boite mail particulière.
C'est la meilleur moyen de ne jamais recevoir de réponse: je reçoit 200
email par jour, et je les lis en diagonale. Enfin, j'image que c'était
une erreur, et que l'e-mail aurait dû partir à la mailing list
matplotlib-dev.

On Tue, Jul 15, 2008 at 06:42:01PM +0200, David Kaplan wrote:
> I have a hopefully simple question that perhaps you could help me with.
> I am trying to add the possibility of manual selection of contour label
> locations to clabel (as in matlab), and I want to use the class
> BlockingMouseInput in contour.py, but I can't figure out how to import
> that class correctly into contour.py.  Could you give me a hint?

Hum, I am not too sure what you are trying to do. It has been a while
since I have used Matlab, so I don't think I know what feature you are
refering too. Could you please elaborate both by describing what you are
trying to achieve in terms of end-user experience, and by giving a simple
example of the code you are trying to get to run.

Cheers,

Gaël

Hi,

I've got (what seems to me) a nice clean, self-contained implementation 
of wind barbs plots.  I'd like to see if I can get this into matplotlib, 
as it would be very useful to the meteorology community.  I've borrowed 
heavily from Quiver for rounding out rough edges (like multiple calling 
signatures) as for templates for documentation.  The base 
implementation, though, seems much simpler (thanks to Mike's transforms) 
and is based more on scatter.

Right now it monkey-patches Axes so that it can be a stand-alone file. 
Just running the file should give a good example of the expected output.

My only concern up front is if a new axes method is appropriate, since 
this is somewhat domain specific.  But I'd like to at least get the new 
Collections class included, since otherwise, I have no idea how to get 
this distributed to the community at large.

I welcome any comments/criticism to help improve this.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Right you are.  Fixed in SVN.

Cheers,
Mike

Ryan May wrote:
> Hi,
>
> I don't think line 96 of collections.py is doing anything:
>
>          if offsets is not None:
>              offsets = np.asarray(offsets, np.float_)
>              if len(offsets.shape) == 1:
>                  offsets = offsets[np.newaxis,:]  # Make it Nx2.
>              if transOffset is not None:
>                  Affine2D = transforms.Affine2D      <----*********
>                  self._offsets = offsets
>                  self._transOffset = transOffset
>              else:
>                  self._uniform_offsets = offsets
>
>          self._pickradius = pickradius
>          self.update(kwargs)
>
> This is in __init__ for Collection, which ends with the code I've pasted 
> here.  It doesn't appear that Affine2D is used and is probably left over 
> cruft.
>
> Ryan
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Ryan May wrote:
> Hi,
> 
> I just hit a bug in PatchCollection, at line 891 in collections.py:
> 
>          if match_original:
>              def determine_facecolor(patch):
>                  if patch.fill():
>                      return patch.get_facecolor()
>                  return [0, 0, 0, 0]
> 
> The problem is that patch.fill is a boolean attribute, not a function. 
> (Or at least it is for polygons and circles.)  You only hit this if you 
> override the default and specify match_original=True.
> 
> Ryan
> 

Fixed in 5764.  Thanks, Ryan.

Eric

Hi,

I don't think line 96 of collections.py is doing anything:

         if offsets is not None:
             offsets = np.asarray(offsets, np.float_)
             if len(offsets.shape) == 1:
                 offsets = offsets[np.newaxis,:]  # Make it Nx2.
             if transOffset is not None:
                 Affine2D = transforms.Affine2D      <----*********
                 self._offsets = offsets
                 self._transOffset = transOffset
             else:
                 self._uniform_offsets = offsets

         self._pickradius = pickradius
         self.update(kwargs)

This is in __init__ for Collection, which ends with the code I've pasted 
here.  It doesn't appear that Affine2D is used and is probably left over 
cruft.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,

I just hit a bug in PatchCollection, at line 891 in collections.py:

         if match_original:
             def determine_facecolor(patch):
                 if patch.fill():
                     return patch.get_facecolor()
                 return [0, 0, 0, 0]

The problem is that patch.fill is a boolean attribute, not a function. 
(Or at least it is for polygons and circles.)  You only hit this if you 
override the default and specify match_original=True.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Sat, Jul 12, 2008 at 4:31 PM, Eric Firing <ef...@ha...> wrote:

> and I am suggesting that this handling of None as a default should
> always be moved to a setter if one exists.  That way, a user can always
> get a property back to its default value by setting it to None.
>
> Does anyone immediately see any problem or disadvantage in this?  (I
> have not looked through the code carefully myself, so I could easily be
> missing something.)

I think localizing the logic into the setters is mostly a win-win
proposition, but there are a couple of points you raised that I want
to comment on.   I consider our overloading of None to mean "do the
default, use rc" something of a wart, since it would be more properly
handled with a proper object or special value, like a *class
RCDefault* instance or a string literal 'rcdefault'.   The None
handling may be a wart we are committed to because of legacy code, or
it may be something we will change, but we should recognize it as a
somewhat non-intuitive wart.  I say "somewhat" because None is used in
other python codes as a default sentinel for mutable keyword arguments
(eg, lists and dicts) but otherwise I do not find it terribly obvious.

The 2nd comment is that I don't find this use case compelling.  Using
None in a setter to mean "restore the rc default" may be consistent
with the __init__ handling, but it is not something that anyone has
ever asked for.  In fact, in the use case that prompted this fix, the
OP intended 'None' rather than None, so the fact that mpl raised on
None rather than reverting to the rc default might be considered a
feature rather than a bug.

So basically, I'm +0 on this proposal.  Better than what we have, not ideal.

JDH

In responding to an inquiry about an exception raised when using

"plot(..., markerfacecolor=None)"

(http://www.mail-archive.com/mat...@li.../msg07627.html)

I made a small change to avoid the problem.  My question is, should the 
following be raised to a general principle, to be followed with at most 
  rare exceptions?

Whenever there is a setter for an artist property, that setter should be 
used in the artist __init__method, with no additional logic, so that a 
kwarg setting in __init__ has the same effect as calling the artist 
update method with that kwarg.

This affects plot in particular because the line property kwargs are not 
used via the __init__ method but are applied by calling update(). 
Typically there is some logic along the lines

if kw is None:
     kw = defkw

and I am suggesting that this handling of None as a default should 
always be moved to a setter if one exists.  That way, a user can always 
get a property back to its default value by setting it to None.

Does anyone immediately see any problem or disadvantage in this?  (I 
have not looked through the code carefully myself, so I could easily be 
missing something.)

Eric

Howdy,

I stumbled upon these two projects which may be of interest to some in mpl land:

- perceptual image diff: http://pdiff.sourceforge.net/

I have no idea if this works well or not, but if it does, it could be
useful for regression testing of mpl, something which has been sorely
missing and normally involves running the test driver, looking for
errors and possibly inspecting plots by hand (or by eye,  as it were).
 I think that mpl would greatly benefit from some form of automatic
testing.

- Graphite: http://graphite.wikidot.com/faq

Python based real-time graphs from large/high rate data sets.  Every
now and then we get posts here asking about doing plots of high
throughput data, a task for which mpl isn't always ideally suited.
This  might be a good alternative in some cases.  I'm sure it doesn't
do any of the sophisticated/scientific plotting many of us need mpl
for, but for some use cases it may be a good tool.

cheers,

f

Hi,

I created a menu for selecting colormaps from a context menu on the
graph.  The attached code cmapmenu.py contains a runnable example.

I've only implemented support for wx.

In general, I would like to be able to add context menu operations
to individual artists on the plot, and will be doing so for my
own applications.  Is this something that could live in the
matplotlib backends?  Are there users of Qt, Gtk, Tk, ... who
are willing to add support for them?

	- Paul

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/
**********************************