matplotlib-devel Mailing List for matplotlib

Hi,

I noticed that offset_copy() went away in the transforms rewrite and was 
replaced with a trans + transfroms.Affine2D().translate(x,y).  This 
works fine for x,y in pixels.  However, offset_copy would also let you 
specify x,y in points.  How can I get that to work with the new 
transforms? More importantly, can I do it without knowing the dpi?

Ryan

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

David M. Kaplan wrote:
> 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.

It sounds like there is time to do it before the release without messing 
up the release.  Just make sure the backend_drivers.py test suite still 
runs OK.  If you can add tests (i.e., examples run by backend_drivers) 
that exercise the new functionality, that is even better.  The 
interactive part of the functionality can't be tested in an automated 
way, but the rest can, and adding an example is a good way to help users 
see how to use it.  In any case, go ahead and commit when ready.

Yes, the labeling code is difficult, and I have not looked at it in a 
long time.  If you are interested, please do look at it from the 
standpoint of a possible major revision that might make it easier to 
understand and easier to enhance.

Eric

> 
> Cheers,
> David
> 
> On Sat, 2008-07-19 at 19:30 -0700,
> mat...@li... 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
>>

On Sat, Jul 19, 2008 at 03:42:27PM -0500, John Hunter wrote:
> On Sat, Jul 19, 2008 at 1:05 AM, Gael Varoquaux
> <gae...@no...> wrote:

> > It turns out it was only in the GTK backend, and quite trivial to
> > correct. Attached is a new patch, including this correction.

> Hey Gael, this is starting to look reasonable.  I know implementing
> these checks, such as detecting whether the mainloop is active, can be
> a hassle, so thanks for taking the time to write against so many
> environments.  We may want to make take the logic you've provided and
> encapsulate them in the backend methods to make them more easily
> recognizable, fixable and reusable.  Eg, each unser interface backend
> would provide a "mainloop_running" method.  You could then access this
> in pyplot to support your fallback logic, and also we could use it in
> "show" to make sure we don't try and start mainloops that are already
> running.

In theory this could work, but the problem is that the logics for
selecting the backend gets executed when matplotlib.backends is imported,
ie before importing any backend. I tried implementing your suggestion,
but it failed because I had to imports from backends. Am I missing
something obvious?

> One thing notice in your patch is that when it comes time to check for
> tk, you import tkinter and then do nothing with it.  I assume this is
> a placeholder until you figure out what you want to do?

I have actually given up on that, so you should probably remove these two
lines. If somebody knows how to check accurately for tk, I am interested.

Cheers,

Gaël

Hi John & All

> The only short term pressure for a point release is coming from
> debian, because they are having some trouble with our last point
> release.  Because debian is an important platform, I want to get a
> point release out that satisfies their problems ASAP, but not before
> we are ready.  Whether this is next week or next month or next year
> will depend on whether the code is ready (I hear echos of Orson Welles
> in the old Paul Masson commercial, "We will sell no wine, before it's
> time").
>
> In the case of the contouring enhancements, they're not ready, so
> we'll wait.  In the situation where debian or some other important
> vendor has a freeze deadline with a critical problem that needs
> fixing, we can always do a branch off the last point release that
> fixes just the required bugs.  Sandro can keep us appraised if such a
> deadline is approaching for 0.98.2.

First of all, I'd like to thank you all for the huge support you're
giving back to Debian.

About deadlines, just yesterday it was announced[1] that general
freeze will happen the next weekend, so it's rather soon :)

We are using the policy "We release when we are ready" and I think
it's a good one, so once you're confident with a new point version,
release :) ; then it will be my responsibility to praise release
managers to include the new version in Debian ;)

Cheers,
Sandro

[1] http://lists.debian.org/debian-devel-announce/2008/07/msg00005.html

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

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,
mat...@li... 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
**********************************

Hi,

As promised, here's a patch to add wind barbs to matplotlib.  This 
should addresses all of the comments I've received as well as all of the 
issues I previously mentioned.  A synopsis of some of the updates:

1) Based on a conversation with Eric Firing, I've gone ahead and added 
the Barbs collection to quiver.py, which seems like a logical place.

2) Method added to set the data components.

3) Masked arrays are handled by saving all of the original arrays and 
using copies fed through delete_masked_points whenever the U/V are updated.

4) Setting the color of the edges/line portion of the barbs was easy, 
thanks to the setting of edgecolor='face' that Eric Firing pointed out. 
    I guess this is a post 0.98.1 addition, since I don't have it in my 
system copy, only SVN.  I also, for some reason, don't remember seeing 
the patch either.  Anyhow, colormapping of the *whole* barb works now.

5) I added an empty circle marker for low wind speeds (vector 
magnitudes).  Accomplishing having the unfilled circle while having the 
barbs filled involved a bit of a "elegant hack".  Using the set of 
vertices that draws the CirclePolygon, I add an additional copy of these 
vertices, basically drawing the circle back the other way.  This is 
basically tricking the drawing algorithm into drawing a really thin 
annulus with a very small gap, but it works perfectly as far as I can 
tell.  It's also somewhat consistent with the way the lines on the barb 
are drawn.  It is *far* simpler than any other solution, which would 
have required somehow mapping a color to each polygon *before* calling
draw_path_collection().  None of the backends I test had a problem, 
including PS, PDF, and SVG (tested with Evince, Firefox, and Acroread).

6) The relative sizes of components of the barb can be controlled by
passing a dictionary in through the sizes keyword parameter.  The 
dictionary has keys 'spacing', 'height', 'width', 'emptybarb', which
map to values which are the size of these components relative to the 
length of the barb. I've also adjust some of the defaults a little so 
that tweaking shouldn't be needed (such as the issue Jeff raised).  This 
seemed a lot better than passing around all of these parameters separately.

7)Driver demo code was moved to barb_demo.py under the pylab_examples. I 
loved Jeff's demo, but obviously that can only go in basemap.

The only issue I've seen is that scaling with PS is way too big.  I've 
attached ps and pdf files from the same run to show the problem.

It should apply fine to SVN, but there are commented lines that should 
be switched with the ones there when set/get_offsets() are added to 
Collections.

Comments and Suggestions?

How do you guys manage committing only parts of your working copy, 
especially when you want to commit part of a file?  I figure there's got 
to be a better way than multiple SVN checkouts and manually editing diffs.

Ryan

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

On Sat, Jul 19, 2008 at 9:48 PM, Ryan May <rm...@gm...> wrote:

> Ok, thanks for the vote of confidence. My (newly created) ID is: ryanmay

Alright, you're now set up for commits.  Keep working closely with
Eric and Jeff and the rest of us on the functionality you are adding.

Welcome aboard!

JDH

John Hunter wrote:
> On Sat, Jul 19, 2008 at 9:30 PM, Ryan May <rm...@gm...> wrote:
>> Take this one instead.  I missed some imports on the last one (oops).
> 
> Hey Ryan -- the code you have been contributing is certainly high
> quality, and I am happy to give you commit rights if you send me your
> sf id.  You should still post here for anything significant so we can
> review and provide input/feedback, but we'd be happy to have you
> making contributions directly.

Ok, thanks for the vote of confidence. My (newly created) ID is: ryanmay

Ryan

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

On Sat, Jul 19, 2008 at 9:30 PM, Ryan May <rm...@gm...> wrote:
> Take this one instead.  I missed some imports on the last one (oops).

Hey Ryan -- the code you have been contributing is certainly high
quality, and I am happy to give you commit rights if you send me your
sf id.  You should still post here for anything significant so we can
review and provide input/feedback, but we'd be happy to have you
making contributions directly.

JDH

On Sat, Jul 19, 2008 at 8:02 PM, Eric Firing <ef...@ha...> wrote:

> 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

Although I may have used the phrase "bugfix release" many times in the
past, I want to clarify my thinking on this.  I distinguish between
point releases and major releases.  With the exception of the
maintenance branch, on which the *only* changes should be bugfixes, I
expect every point release to have new features and bugfixes.  When we
decide to bump the major version is of course subjective, but it
normally comes when a number of significant features have been
introduced, and it should be comparatively rare, 2 to 4 times a year
or so.  But I expect and want new features in every point release.

We are fortunate that we have a lot of developers, and Charlie is a
very responsive release manager.  I would rather err on the side of
getting new features out, tested to the best of our abilities, with
the understanding that if we break something important we will roll
out a point release that fixes a critical bug within 12 to 24 hours,
and hide the broken release in the mean time.  Release early, release
often.
My aversion to branches stems not from the weaknesses in svn merge,
which may be better in hg or other version control systems.  The
reason I wnat people contributing to the trunk is that I want as many
people testing and using the code as possible so we can find and fix
the bugs before they are released.  While Michael's transforms
refactoring was so significant that it absolutely required a branch,
we did not start finding the bugs until we made his branch the trunk,
and even then did not find the bulk of them.  We found them when we
released the code.  More tests will help, and we should have as many
tests as we can muster, but until we have bullet-proof tests we have
to leverage our developers and users as testers.

The only short term pressure for a point release is coming from
debian, because they are having some trouble with our last point
release.  Because debian is an important platform, I want to get a
point release out that satisfies their problems ASAP, but not before
we are ready.  Whether this is next week or next month or next year
will depend on whether the code is ready (I hear echos of Orson Welles
in the old Paul Masson commercial, "We will sell no wine, before it's
time").

In the case of the contouring enhancements, they're not ready, so
we'll wait.  In the situation where debian or some other important
vendor has a freeze deadline with a critical problem that needs
fixing, we can always do a branch off the last point release that
fixes just the required bugs.  Sandro can keep us appraised if such a
deadline is approaching for 0.98.2.

JDH

John Hunter wrote:
> On Sat, Jul 19, 2008 at 8:58 PM, Ryan May <rm...@gm...> wrote:
>> Hi,
>>
>> In integrating my barbs work, I'm having trouble that causes a circular
>> import. I used delete_masked_points from axes.  The problem here is that
>> axes imports quiver (where I put barbs) which then has to (in some form)
>> import axes to get delete_masked_points.  Anyone have something I'm
>> missing here? Or can I move delete_masked_points to a better location?
> 
> mlab or cbook would be fine
> 
> JDH
Take this one instead.  I missed some imports on the last one (oops).

Ryan

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

John Hunter wrote:
> On Sat, Jul 19, 2008 at 8:58 PM, Ryan May <rm...@gm...> wrote:
>> Hi,
>>
>> In integrating my barbs work, I'm having trouble that causes a circular
>> import. I used delete_masked_points from axes.  The problem here is that
>> axes imports quiver (where I put barbs) which then has to (in some form)
>> import axes to get delete_masked_points.  Anyone have something I'm
>> missing here? Or can I move delete_masked_points to a better location?
> 
> mlab or cbook would be fine
> 
> JDH

Here's a patch to do just that.

Ryan

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

John Hunter wrote:
> On Sat, Jul 19, 2008 at 8:58 PM, Ryan May <rm...@gm...> wrote:
>> Hi,
>>
>> In integrating my barbs work, I'm having trouble that causes a circular
>> import. I used delete_masked_points from axes.  The problem here is that
>> axes imports quiver (where I put barbs) which then has to (in some form)
>> import axes to get delete_masked_points.  Anyone have something I'm
>> missing here? Or can I move delete_masked_points to a better location?
> 
> mlab or cbook would be fine
> 

cbook seems like a better home for utility functions like this.

Eric

On Sat, Jul 19, 2008 at 8:58 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> In integrating my barbs work, I'm having trouble that causes a circular
> import. I used delete_masked_points from axes.  The problem here is that
> axes imports quiver (where I put barbs) which then has to (in some form)
> import axes to get delete_masked_points.  Anyone have something I'm
> missing here? Or can I move delete_masked_points to a better location?

mlab or cbook would be fine

JDH

Hi,

In integrating my barbs work, I'm having trouble that causes a circular 
import. I used delete_masked_points from axes.  The problem here is that 
axes imports quiver (where I put barbs) which then has to (in some form) 
import axes to get delete_masked_points.  Anyone have something I'm 
missing here? Or can I move delete_masked_points to a better location?

Ryan

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

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


In [1]:run contour_demo.py
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)

/home/efiring/programs/py/mpl/mpl_trunk/examples/pylab_examples/contour_demo.py 
in <module>()
      82            inline=1,
      83            fmt='%1.1f',
---> 84            fontsize=14)
      85
      86 # make a colorbar for the contour lines

/usr/local/lib/python2.5/site-packages/matplotlib/pyplot.pyc in 
clabel(*args, **kwargs)
    1698         hold(h)
    1699     try:
-> 1700         ret =  gca().clabel(*args, **kwargs)
    1701         draw_if_interactive()
    1702     except:

/usr/local/lib/python2.5/site-packages/matplotlib/axes.pyc in 
clabel(self, CS, *args, **kwargs)
    5996
    5997     def clabel(self, CS, *args, **kwargs):
-> 5998         return CS.clabel(*args, **kwargs)
    5999     clabel.__doc__ = mcontour.ContourSet.clabel.__doc__
    6000

/usr/local/lib/python2.5/site-packages/matplotlib/contour.pyc in 
clabel(self, *args, **kwargs)
     150             blocking_contour_labeler(inline)
     151         else:
--> 152             self.labels(inline)
     153
     154         self.label_list =  cbook.silent_list('text.Text', self.cl)

/usr/local/lib/python2.5/site-packages/matplotlib/contour.pyc in 
labels(self, inline)
     451                 if self.print_label(slc,lw):
     452                     x,y, rotation, ind  = 
self.locate_label(slc, lw)
--> 453                     self.add_label(x,y,rotation,icon)
     454
     455                     if inline:

/usr/local/lib/python2.5/site-packages/matplotlib/contour.pyc in 
add_label(self, x, y, rotation, icon)
     364                       verticalalignment='center')
     365
--> 366         color = 
self.label_mappable.to_rgba(self.label_cvalues[icon],
     367                                             alpha=self.alpha)
     368

IndexError: index out of bounds
 > 
/usr/local/lib/python2.5/site-packages/matplotlib/contour.py(366)add_label()
     365
--> 366         color = 
self.label_mappable.to_rgba(self.label_cvalues[icon],
     367                                             alpha=self.alpha)

ipdb> icon
7
ipdb> self.label_cvalues
array([-1. , -0.6, -0.2,  0.2,  0.6,  1. ,  1.4])

Eric Firing wrote:
> Ryan May wrote:
>   
>> Eric Firing wrote:
>>     
>>> Ryan May wrote:
>>>       
>>>> Hi,
>>>>
>>>> In looking over trying to support masked arrays in wind barbs, I noticed
>>>> a problem.  I had originally copied the model of quiver, wherein masked
>>>> arrays are supported for U,V, and color, but not for X,Y.  This stems
>>>> from the seemingly nonsensical nature of masking a location.  
>>>> However, if nothing is drawn for a location X,Y where U,V are masked, 
>>>> this would seemingly lead to a problem where the locations and the 
>>>> things to be drawn get out of phase.  Am I missing something here? 
>>>> Eric, did I miss some magic somewhere in quiver that handles this?
>>>>         
>>  >>
>>     
>>> There is no magic; we are not compressing or otherwise extracting the 
>>> valid values, but are leaving the masking of U and V in place through 
>>> the creation of the arrow vertices.  It is the PolyCollection.draw() 
>>> method that is then handling the masking.
>>>
>>> Now, having said that, and having traced through the code,  I am not 
>>> at all sure that everything in collections is still working correctly 
>>> as described; I will have to look a bit more.
>>>
>>> Note that the path module itself can handle masking now, so masked 
>>> arrays sometimes get passed all the way through to it.
>>>       
>> So you mean the list/array of vertices can contain masked values?
>>     
>
> Yes.  But again, trying to trace data values through various paths in 
> the code, it can be hard to keep track of what assumptions are being 
> made at each stage.  I think the present intention is that masked values 
> are passed through, but I also think I saw a recent code addition 
> (maybe...) that does not do this.  I need to check.
>
>   
>>> Quiver and windbarb could use the axes.delete_masked_points function 
>>> right at the start, and this might be a good change to make, except 
>>> that   it is inconsistent with using the present set_UVC method to 
>>> update arrows at constant locations.
>>>       
>> delete_masked_points() looks to me like a sane way to go.  I'll update 
>> my masked handling to use this.
>>     
>
> It can be OK if your windbarb is intended as a one-shot instance--that 
> is, the user makes another one if the data change--which is probably OK.
>
> delete_masked_points looks to me like it has its own problems in the 
> whole mpl-with-units context, including a recent change that I suspect 
> breaks the handling of datetime inputs, but I don't think that any 
> changes or cleanups will affect your use of it.

I suspect that your concern may be referring to my recent change. I
started some unit tests for delete_masked_points() (in
unit/axes_unit.py) when I made the modifications, so if you have use
cases, put 'em in there...

-Andrew

Thanks for the help, Ryan and Eric.

On Sat, Jul 19, 2008 at 7:27 PM, Eric Firing <ef...@ha...> wrote:
> Ryan,
>
> Thanks.  I will take care of this one way or another, but I want to see
> whether we really need both _uniform_offsets and _offsets.
>
> Eric
>
> Ryan May wrote:
>> John Hunter wrote:
>>> On Thu, Jul 17, 2008 at 10:28 PM, Ryan May <rm...@gm...> wrote:
>>>
>>>> I helped Eric out with this offline, and obviously set_array is for the
>>>> colors, but the only solution we could come up with was to directly
>>>> reset the PolyCollection._offsets member.  This seems a little hacky.
>>>> Is there any reason that there is not an set_offsets() (or something
>>>> like it)?  Any reason why I shouldn't code up a patch?
>>>
>>> No, I can't thing of any reason why this attribute should not be
>>> publicly settable, so patch away.
>>
>> Here's an updated version of the patch so that the doctring actually
>> makes sense.
>>
>> Ryan
>>

Eric Firing wrote:
>>> Quiver and windbarb could use the axes.delete_masked_points function 
>>> right at the start, and this might be a good change to make, except 
>>> that   it is inconsistent with using the present set_UVC method to 
>>> update arrows at constant locations.
>>
>> delete_masked_points() looks to me like a sane way to go.  I'll update 
>> my masked handling to use this.
> 
> It can be OK if your windbarb is intended as a one-shot instance--that 
> is, the user makes another one if the data change--which is probably OK.
> 
> delete_masked_points looks to me like it has its own problems in the 
> whole mpl-with-units context, including a recent change that I suspect 
> breaks the handling of datetime inputs, but I don't think that any 
> changes or cleanups will affect your use of it.

What I've tried to do is keep copies of the original data passed in, and 
when updating UV or offsets, use delete_masked_points to keep them lined 
  up as appropriate.  Does this sound reasonable?  It doesn't look too 
bad, and still keeps an interface that allows updating.

Ryan

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