matplotlib-devel Mailing List for matplotlib

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.

Eric

> 
> Ryan
> 

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

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

Jeff Whitaker wrote:

> John:  Well, I hit one snag.  One file in natgrid has this comment in it.
> 
> /*
>  *  The code in this file is based on code written and
>  *  copyrighted (C) by Dave Watson.  Dr. Watson retains the
>  *  copyright to his original code.  Augmentations and changes
>  *  to Dr. Watson's code are copyrighted (C) by UCAR, 1997.
>  */
> 
> The NCAR folks have not been able to contact the fellow, and suspect he 
> may have passed on.  I can't verify this though.  Do you see this as a 
> problem?

It was for me. That's why I wrote scikits.delaunay in the first place. That, and 
the nngridr code's an uncommented mass of nested ifs.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

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?

> 
> 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.

Ryan

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

Ryan May wrote:
> John Hunter wrote:
>> Fernando and Gael proposed supporting a backend fallback option so the
>> user could express the intention: use my default backend unless I
>> happen to be in an incompatible user interface environment and then
>> just choose the most sensible thing.  Users who do not want this magic
>> can simply turn the fallback option off.  This behavior will only be
>> triggered if
>>
>>   1) the fallback option is on (it will be by default)
>>   2) the user is running mpl in an environment in which a user
>> interface already has a running mainloop
>>   3) the default backend is known to be incompatible.  Eg, if the
>> default backend is PS, nothing will happen.
>>
>> I think the proposed changes are reasonable.
>>
> +1

I agree.  Sounds like progress.

Eric

> 
> Ryan
> 

Ryan May wrote:
> Hi,
> 
> In trying to add a symbol for an empty wind barb, I ran into problem. 
> Traditionally, a smaller, non-filled circle is used for low wind speeds 
> when doing a barb plot.  I can draw the circle easily as a polygon, 
> using CirclePolygon from patches, but unfortunately, the fill color for 
> this polygon ends up being the same as the color of the flags on the 
> barbs.  Therefore, as currently implemented, the only way to have 
> unfilled circles is to have unfilled flags.
> 
> The only technical solution I can think of here is to have separate 
> collections for the circles and the polygons.  Unfortunately, I have no 
> idea how to begin to do that within a class that inherits from 
> collections.  Another option would be to somehow manually set the fill 
> colors on the circles after the collection is initialized.  Anyone have 
> suggestions on how to make this work, or maybe a better technical solution.

Ryan,

Yes, this would require some bigger changes.  Instead of inheriting from 
PolyCollection, it would have to contain two collections, or a 
collection and a Line2D with markers.

An alternative would be to override the PolyCollection.draw() method 
with a near-copy, but with logic added right before the renderer call to 
  set the alpha (column 3) of the rgba array to zero for the circles.

A better way might be to modify the original draw method to use 
self.get_facecolors() instead of self._facecolors; then one could 
override the get_facecolors method, which would require much less code.

Eric

> 
> Jeff, how aesthetically displeasing do you think it would be to have 
> small (possibly colored) circles to represent the low winds instead of 
> the traditional (somewhat larger) hollow circle?  It would make it 
> impossible to do sky cover in a traditional surface map, but maybe 
> Z-ordering could be used to hack around it.
> 
> Thoughts,
> 
> Ryan
> 

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?
> 
> Ryan
> 

Ryan,

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.

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.

Eric

Hi,

As promised, here's a short patch to add get_offsets() and set_offsets() 
to the Collections() base class.  I tried to make it do the right thing 
with regard to _offsets vs. _uniform_offsets, depending on whether 
_uniform_offsets is None.  I also had tried to make __init__ use 
set_offsets, but that proved to be too much of a hassle for too little 
code reuse.

Comments?

Ryan

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

John Hunter wrote:
> Fernando and Gael proposed supporting a backend fallback option so the
> user could express the intention: use my default backend unless I
> happen to be in an incompatible user interface environment and then
> just choose the most sensible thing.  Users who do not want this magic
> can simply turn the fallback option off.  This behavior will only be
> triggered if
> 
>   1) the fallback option is on (it will be by default)
>   2) the user is running mpl in an environment in which a user
> interface already has a running mainloop
>   3) the default backend is known to be incompatible.  Eg, if the
> default backend is PS, nothing will happen.
> 
> I think the proposed changes are reasonable.
> 
+1

Ryan

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

Hi,

In trying to add a symbol for an empty wind barb, I ran into problem. 
Traditionally, a smaller, non-filled circle is used for low wind speeds 
when doing a barb plot.  I can draw the circle easily as a polygon, 
using CirclePolygon from patches, but unfortunately, the fill color for 
this polygon ends up being the same as the color of the flags on the 
barbs.  Therefore, as currently implemented, the only way to have 
unfilled circles is to have unfilled flags.

The only technical solution I can think of here is to have separate 
collections for the circles and the polygons.  Unfortunately, I have no 
idea how to begin to do that within a class that inherits from 
collections.  Another option would be to somehow manually set the fill 
colors on the circles after the collection is initialized.  Anyone have 
suggestions on how to make this work, or maybe a better technical solution.

Jeff, how aesthetically displeasing do you think it would be to have 
small (possibly colored) circles to represent the low winds instead of 
the traditional (somewhat larger) hollow circle?  It would make it 
impossible to do sky cover in a traditional surface map, but maybe 
Z-ordering could be used to hack around it.

Thoughts,

Ryan

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

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.

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?

For a little background, Fernando, Gael and I talked about this
problem a bit over the phone yesterday.  The use case they are trying
to address is that people may be wanting to use more than one
application, at different times or at the same time, that have
embedded python shells.  With all the work going on making ipython
frontends for wx, qt and gtk, it is not unreasonable to assume that
there ill soon be multiple IDEs or other environment in which one
might want to import and use pylab.  Since we only support one default
backend, and it is dificult and onerous for the user to constantly
modify their rc depending on what application they may be launching,
Fernando and Gael proposed supporting a backend fallback option so the
user could express the intention: use my default backend unless I
happen to be in an incompatible user interface environment and then
just choose the most sensible thing.  Users who do not want this magic
can simply turn the fallback option off.  This behavior will only be
triggered if

  1) the fallback option is on (it will be by default)
  2) the user is running mpl in an environment in which a user
interface already has a running mainloop
  3) the default backend is known to be incompatible.  Eg, if the
default backend is PS, nothing will happen.

I think the proposed changes are reasonable.

JDH

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?

Ryan

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

             if (hasattr(x, 'get_compressed_copy')):
                 compressed_x = x.get_compressed_copy(mask)

John,

You added the snippet above to axes.delete_masked_points as part of one 
of your massive "units" patches.  It needs at least a comment in the 
code--which I would be happy to add, based on your reply--because I 
don't see any such attribute in mpl or numpy.  My guess is that it is 
specific to the JPL array-like objects which motivated the units support.

Thanks.

Eric

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

On Sat, Jul 19, 2008 at 07:31:19AM +0200, Gael Varoquaux wrote:
>   - show starts a mainloop and is blocking even if there are not windows
>     open. This basically leads to a deadlock where the user cannot
>     interrupt the mainloop. This can probably be easily fixed, and I'll
>     look into it.

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

Gaël

I forgot to mention: fltk and cocoa did not get any love at all in this
patch. The reason being that I do not know of any program running the
first one, and for me to test and develop things for the second one,
somebody will have to offer me an apple computer :).

Cheers,

Gaël

I have implemented a prototype of interactive backend detection. As I
proposed earlier, I added an extra rc parameter 'backend_fallback' that
allows pyplot to inspect sys.modules on load and try to redirect
interactive backends to the appropriate ones.

I am attaching a patch, not for inclusion, as I still want to check
different details on interactivity, and the behavior of the show command,
but for comments and triage. I have tested it in various apps, and I
think it is interesting to review the different mainstream apps
presenting a interactive shell in which pylab can be used interactively.

* wx apps. In mayavi2, my near-born ipython frontend the attached patch 
 works seamlessly, with or without the interactive switch. In SPE 
 (wx-based IDE) it does not work, and I suspect this is because of ugly 
 things SPE does to the wx image-loading, for theming reasons, as I see
 totally unrelated errors. 

* Qt: In Eric4 the qt detection does not work as it seems that Eric 
  spawns a new python process. As a result, as long as you keep the 
  interactive switch off, pylab works great, but you really have to use a 
  blocking show. Does anybody now a Qt program that has an interactive
  Python prompt?

* In IDLE I can't figure out what is happening. I must confess that I do not 
  know much about Tkinter, and I am not too sure how matplotlib is
  supposed to collaborate with an existing Tk mainloop.

* The only GTK program I could think of with an interactive python prompt
  was accerciser, an pylab now works out of the box there, in interactive
  mode or not.

Of course in ipython -q|q4|w|g-thread, my addition work seamlessly, but
that was too easy :).

Some remarks that came out of this extensive testing:

  - show starts a mainloop and is blocking even if there are not windows
    open. This basically leads to a deadlock where the user cannot
    interrupt the mainloop. This can probably be easily fixed, and I'll
    look into it.

  - we cannot guess whether the user want to be in interactive mode or
    not: there is a potential large cost of being in interactive mode due to 
    continuous refreshing of the UI. Ipython gets it right by turning the
    interactive mode off when running a script, but when need the host
    environment to make this decision and we cannot make it in matplotlib.
    However, I believe it is important to expose more this
    functionality, as the user will now probably have to make this
    decision. This is why I have add the import of "interactive" in
    pyplot.

  - this brings up the fact that the user experience can be increased a
    lot if the host environment collaborates with matplotlib. This is why
    we discussed with John the idea of adding a "vendor registry", a
    light-weight module that an environment could import at little cost
    to tell matplotlib what backend to use, whether to put the
    interactive switch, and hopefully more, like maybe a factory to
    create new figure, as this would allow embedding these figures in an IDE.
    We do this with mayavi2, where the figures created by mlab are
    standalone windows when the fullblown environment is not running, but
    integrated windows when it is running.

I am sure there is more that we can learn. Please come up with ideas so
that we can see better what is the way forward for integrating matplotlib
to graphical shells and environments.

Cheers,

Gaël