matplotlib-users Mailing List for matplotlib (Page 64)

2014-08-25 0:03 GMT+02:00 Johan Ekh <ekh...@gm...>:
> Hi all
>
> I try to use yticks as
>
> plt.yticks(y_pos, projDescr)
>
> where projDescr is a list of strings that contains some swedish letters,
> i.e. åäö, but they are not printed correctly. I have googled but can not
> fins a solution. Can someone point me in the right direction?
>
> Best regards,
> Johan
>
Hi,
I am not sure, whether this is the same problem I encountered with
Czech diacritics in matplotlib some time ago, but it definitively
looks similar to me.
You can check the respective thread and the mentioned workaround there:
http://matplotlib.1069221.n5.nabble.com/font-setting-in-matplotlib-1-3-1-td42662.html

Basically, it seems to be a problem with font selection with regard to
Bitstream Vera;
a workaround consist in manipulating rcParams and removing this item
from the list of usable fonts.
hth,
  vbr

Hi all

I try to use yticks as

plt.yticks(y_pos, projDescr)

where projDescr is a list of strings that contains some swedish letters,
i.e. åäö, but they are not printed correctly. I have googled but can not
fins a solution. Can someone point me in the right direction?

Best regards,
Johan

Hi all,

I'm trying to customize the minor tick marks on a matplotlib colorbar. I've
posted a question on StackOverflow about this:

http://stackoverflow.com/questions/25454532/logarithmically-scaled-minor-tick-marks-on-a-matplotlib-colorbar

Thanks in advance for your help!

-Nathan

I think there is: for a zoom/pan, the mouse must move a certain distance 
to be considered the start of a zoom or pan (button down -> drag -> 
button up). A pick can be just a click (button down -> button up, no or 
minimal change in mouse position <1,2 pts?).

M

On 8/21/14 3:22 PM, Benjamin Root wrote:
> Pick events, by default, won't fire while the zoom/pan tool is active,
> because there is no way to distinguish between a "pick" click, and a
> click for performing a zoom/pan.

Pick events, by default, won't fire while the zoom/pan tool is active,
because there is no way to distinguish between a "pick" click, and a click
for performing a zoom/pan. So, the question is really, is it sensible to
keep the tools active after their action. I think it is, particularly when
considering the panning tool, as it may take multiple "pans" before I
finding what I want.

You can easily turn the various tools on and off via keyboard shortcuts:
http://matplotlib.org/users/navigation_toolbar.html#navigation-keyboard-shortcuts
Command Keyboard Shortcut(s)  Home/Reset *h* or *r* or *home* Back *c* or *left
arrow* or *backspace* Forward *v* or *right arrow* Pan/Zoom *p* Zoom-to-rect
*o* Save *ctrl* + *s* Toggle fullscreen *ctrl* + *f* Close plot *ctrl*
+ *w* Constrain
pan/zoom to x axis hold *x* when panning/zooming with mouse Constrain
pan/zoom to y axis hold *y* when panning/zooming with mouse Preserve aspect
ratio hold *CONTROL* when panning/zooming with mouse Toggle grid *g* when
mouse is over an axes Toggle x axis scale (log/linear) *L* or *k* when
mouse is over an axes Toggle y axis scale (log/linear) *l* when mouse is
over an axes
Does this solve the issue, or do we need something more configurable?

Cheers!
Ben Root



On Thu, Aug 21, 2014 at 3:02 PM, Joe Kington <jof...@gm...> wrote:

> I think the OP's desire is to have pick events fire after the zoom has
> been triggered.
>
> Currently, after you zoom (or pan), the zoom tool is still active until
> you click it again.  Pick events won't fire while the zoom tool is the
> selected tool, and you have to manually de-select it (i.e. click the zoom
> button again for pick events to work).
>
> The current behavior is the right default choice, i.m.o., but it's
> counter-intuitive when combined with pick events.
>
> When you're building a gui to interact with data (or, for example, when
> using mpldatacursor -- this is a question I get a lot), a common
> expectation is that after you zoom once, the zoom tool is no longer
> active.  Pick events should work again.
>
> Currently, you have to subclass (or monkey-patch) the toolbar to make this
> happen.  It's a bit of a pain.  (It's more complicated that just setting
> `fig.canvas.toolbar._active`.)  (If I'm wrong about that, please let me
> know!!!)
>
> It would be nice to have an easier way to "deactivate" the zoom/pan tool.
> I think the "new" toolbar might have that, but I haven't checked.
>
> Cheers,
> -Joe
>
>
> On Thu, Aug 21, 2014 at 1:41 PM, Benjamin Root <ben...@ou...> wrote:
>
>> Imagine someone creates some event that would modify an artist upon
>> picking, or do some expensive calculation, or some other action. But, I
>> seriously doubt anybody would want those actions to fire while using the
>> zoom/pan tool. Especially since the mouse cursor looks totally different. I
>> am curious why you would expect pick events to fire while using pan/zoom.
>> What is the user-story that compels that expectation? Perhaps I could be
>> convinced otherwise to offer some sort of toggle.
>>
>>
>>
>> On Thu, Aug 21, 2014 at 2:33 PM, Michael Kaufman <kau...@or...>
>> wrote:
>>
>>> What kind of bad stuff happens if we were to allow that?
>>>
>>> M
>>>
>>>
>>> On 8/21/14 2:29 PM, Benjamin Root wrote:
>>>
>>>> Yes, those tools do "snarf" up pick events via the widgetlock mechanism,
>>>> IIRC. This is entirely intentional, and I an not sure there is a bug
>>>> here to fix.
>>>>
>>>>
>>>> On Thu, Aug 21, 2014 at 12:01 PM, Thomas Caswell <tca...@gm...
>>>> <mailto:tca...@gm...>> wrote:
>>>>
>>>>     On Thu, Aug 21, 2014 at 9:44 AM, Michael Kaufman <
>>>> kau...@or...
>>>>     <mailto:kau...@or...>> wrote:
>>>>      >
>>>>      >    # plot axvlines here... etc.
>>>>      >
>>>>      >    global cids
>>>>      >
>>>>      >    # remove any previous connections
>>>>      >    for i in cids:
>>>>      >       gcf().canvas.mpl_disconnect(i)
>>>>      >    cids = []
>>>>      >
>>>>      >    cids.append(gcf().canvas.mpl_connect('pick_event',self.pick))
>>>>      >
>>>>     cids.append(gcf().canvas.mpl_connect('button_press_event',
>>>> self.click))
>>>>      >
>>>>      >    draw()
>>>>      >
>>>>      > def pick(self, event):
>>>>      >    thisline = event.artist
>>>>      >    xdata, ydata = thisline.get_data()
>>>>      >    print xdata[0]
>>>>      >
>>>>      > def click(self, event):
>>>>      >    print "clicked"
>>>>
>>>>
>>>>     See this minimal example
>>>>
>>>>     ```
>>>>     import matplotlib.pyplot as plt
>>>>     fig, ax = plt.subplots()
>>>>
>>>>     ax.axvline(.5, picker=6)
>>>>     ax.plot(range(3))
>>>>     cids = []
>>>>
>>>>     plt.draw()
>>>>
>>>>     def pick(event):
>>>>         thisline = event.artist
>>>>         xdata, ydata = thisline.get_data()
>>>>         print xdata[0]
>>>>
>>>>     def click(event):
>>>>         print "clicked"
>>>>
>>>>
>>>>     cids.append(fig.canvas.mpl_connect('pick_event', pick))
>>>>     cids.append(fig.canvas.mpl_connect('button_press_event', click))
>>>>
>>>>     ```
>>>>
>>>>     If you turn the zoom/pan tool off the picker works again.  I suspect
>>>>     that there is some logic underneath those tools that are snarfing
>>>>     events when the are turned on to avoid messy conflicts.  There is
>>>> some
>>>>     work going on (MEP22 iirc) to update the toolbar and make our tool
>>>>     handling saner.
>>>>
>>>>     Tom
>>>>     --
>>>>     Thomas Caswell
>>>>     tca...@gm... <mailto:tca...@gm...>
>>>>
>>>>
>>>>     ------------------------------------------------------------
>>>> ------------------
>>>>     Slashdot TV.
>>>>     Video for Nerds.  Stuff that matters.
>>>>     http://tv.slashdot.org/
>>>>     _______________________________________________
>>>>     Matplotlib-users mailing list
>>>>     Mat...@li...
>>>>     <mailto:Mat...@li...>
>>>>     https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>

Hmm, maybe my expectations are not common. Generally when I'm zooming in 
on data, I want to zoom multiple times one right after another.

You always want this behavior when you're panning: you don't want the 
pan tool to deselect after you release the button. I'm not quite sure 
why anyone would want a different behavior with zoom (so I guess I'm 
agreeing that the current behavior with respect to keeping zoom tool 
selected is the right choice).

I'm just bit confused on what the big deal is. Click to pick, Click and 
drag to get your zoom box.

My suggestion would be something similar to the Inkscape tool interface. 
The spacebar switches between the select tool and the last-used tool.

M

On 8/21/14 3:02 PM, Joe Kington wrote:
> I think the OP's desire is to have pick events fire after the zoom has
> been triggered.
>
> Currently, after you zoom (or pan), the zoom tool is still active until
> you click it again.  Pick events won't fire while the zoom tool is the
> selected tool, and you have to manually de-select it (i.e. click the
> zoom button again for pick events to work).
>
> The current behavior is the right default choice, i.m.o., but it's
> counter-intuitive when combined with pick events.
>
> When you're building a gui to interact with data (or, for example, when
> using mpldatacursor -- this is a question I get a lot), a common
> expectation is that after you zoom once, the zoom tool is no longer
> active.  Pick events should work again.
>
> Currently, you have to subclass (or monkey-patch) the toolbar to make
> this happen.  It's a bit of a pain.  (It's more complicated that just
> setting `fig.canvas.toolbar._active`.)  (If I'm wrong about that, please
> let me know!!!)
>
> It would be nice to have an easier way to "deactivate" the zoom/pan
> tool.  I think the "new" toolbar might have that, but I haven't checked.
>
> Cheers,
> -Joe
>

On 2014-08-21 11:55, Michael Kaufman wrote:> My user-story is that I 
have say several axvlines very close together in
 > bunches in the standard xlim(). Take for example spectral lines (or 
fits
 > to spectral lines). I want to pick a line and have the program tell me
 > the x-location of that line. Since they're close together I need to 
zoom
 > in to discriminate them. I don't want to have to zoom in, then move the
 > mouse to unselect the zoom tool before moving the mouse back to do the
 > pick or multiple picks.

	It sounds like a possible solution would be keyboard shortcuts for 
the toolbar tools, so that zoom could be activated/deactivated without 
moving the mouse.

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is 
no path, and leave a trail."
    --author unknown

I think the OP's desire is to have pick events fire after the zoom has been
triggered.

Currently, after you zoom (or pan), the zoom tool is still active until you
click it again.  Pick events won't fire while the zoom tool is the selected
tool, and you have to manually de-select it (i.e. click the zoom button
again for pick events to work).

The current behavior is the right default choice, i.m.o., but it's
counter-intuitive when combined with pick events.

When you're building a gui to interact with data (or, for example, when
using mpldatacursor -- this is a question I get a lot), a common
expectation is that after you zoom once, the zoom tool is no longer
active.  Pick events should work again.

Currently, you have to subclass (or monkey-patch) the toolbar to make this
happen.  It's a bit of a pain.  (It's more complicated that just setting
`fig.canvas.toolbar._active`.)  (If I'm wrong about that, please let me
know!!!)

It would be nice to have an easier way to "deactivate" the zoom/pan tool.
I think the "new" toolbar might have that, but I haven't checked.

Cheers,
-Joe


On Thu, Aug 21, 2014 at 1:41 PM, Benjamin Root <ben...@ou...> wrote:

> Imagine someone creates some event that would modify an artist upon
> picking, or do some expensive calculation, or some other action. But, I
> seriously doubt anybody would want those actions to fire while using the
> zoom/pan tool. Especially since the mouse cursor looks totally different. I
> am curious why you would expect pick events to fire while using pan/zoom.
> What is the user-story that compels that expectation? Perhaps I could be
> convinced otherwise to offer some sort of toggle.
>
>
>
> On Thu, Aug 21, 2014 at 2:33 PM, Michael Kaufman <kau...@or...>
> wrote:
>
>> What kind of bad stuff happens if we were to allow that?
>>
>> M
>>
>>
>> On 8/21/14 2:29 PM, Benjamin Root wrote:
>>
>>> Yes, those tools do "snarf" up pick events via the widgetlock mechanism,
>>> IIRC. This is entirely intentional, and I an not sure there is a bug
>>> here to fix.
>>>
>>>
>>> On Thu, Aug 21, 2014 at 12:01 PM, Thomas Caswell <tca...@gm...
>>> <mailto:tca...@gm...>> wrote:
>>>
>>>     On Thu, Aug 21, 2014 at 9:44 AM, Michael Kaufman <kau...@or...
>>>     <mailto:kau...@or...>> wrote:
>>>      >
>>>      >    # plot axvlines here... etc.
>>>      >
>>>      >    global cids
>>>      >
>>>      >    # remove any previous connections
>>>      >    for i in cids:
>>>      >       gcf().canvas.mpl_disconnect(i)
>>>      >    cids = []
>>>      >
>>>      >    cids.append(gcf().canvas.mpl_connect('pick_event',self.pick))
>>>      >
>>>     cids.append(gcf().canvas.mpl_connect('button_press_event',
>>> self.click))
>>>      >
>>>      >    draw()
>>>      >
>>>      > def pick(self, event):
>>>      >    thisline = event.artist
>>>      >    xdata, ydata = thisline.get_data()
>>>      >    print xdata[0]
>>>      >
>>>      > def click(self, event):
>>>      >    print "clicked"
>>>
>>>
>>>     See this minimal example
>>>
>>>     ```
>>>     import matplotlib.pyplot as plt
>>>     fig, ax = plt.subplots()
>>>
>>>     ax.axvline(.5, picker=6)
>>>     ax.plot(range(3))
>>>     cids = []
>>>
>>>     plt.draw()
>>>
>>>     def pick(event):
>>>         thisline = event.artist
>>>         xdata, ydata = thisline.get_data()
>>>         print xdata[0]
>>>
>>>     def click(event):
>>>         print "clicked"
>>>
>>>
>>>     cids.append(fig.canvas.mpl_connect('pick_event', pick))
>>>     cids.append(fig.canvas.mpl_connect('button_press_event', click))
>>>
>>>     ```
>>>
>>>     If you turn the zoom/pan tool off the picker works again.  I suspect
>>>     that there is some logic underneath those tools that are snarfing
>>>     events when the are turned on to avoid messy conflicts.  There is
>>> some
>>>     work going on (MEP22 iirc) to update the toolbar and make our tool
>>>     handling saner.
>>>
>>>     Tom
>>>     --
>>>     Thomas Caswell
>>>     tca...@gm... <mailto:tca...@gm...>
>>>
>>>
>>>     ------------------------------------------------------------
>>> ------------------
>>>     Slashdot TV.
>>>     Video for Nerds.  Stuff that matters.
>>>     http://tv.slashdot.org/
>>>     _______________________________________________
>>>     Matplotlib-users mailing list
>>>     Mat...@li...
>>>     <mailto:Mat...@li...>
>>>     https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

My user-story is that I have say several axvlines very close together in 
bunches in the standard xlim(). Take for example spectral lines (or fits 
to spectral lines). I want to pick a line and have the program tell me 
the x-location of that line. Since they're close together I need to zoom 
in to discriminate them. I don't want to have to zoom in, then move the 
mouse to unselect the zoom tool before moving the mouse back to do the 
pick or multiple picks.

M

PS: In GTKAgg at least, the zoom tool has a cross-hair pointer which in 
my opinion is even better than the arrow.

On 8/21/14 2:41 PM, Benjamin Root wrote:
> Imagine someone creates some event that would modify an artist upon
> picking, or do some expensive calculation, or some other action. But, I
> seriously doubt anybody would want those actions to fire while using the
> zoom/pan tool. Especially since the mouse cursor looks totally
> different. I am curious why you would expect pick events to fire while
> using pan/zoom. What is the user-story that compels that expectation?
> Perhaps I could be convinced otherwise to offer some sort of toggle.
>
>
>
> On Thu, Aug 21, 2014 at 2:33 PM, Michael Kaufman <kau...@or...
> <mailto:kau...@or...>> wrote:
>
>     What kind of bad stuff happens if we were to allow that?
>
>     M
>
>
>     On 8/21/14 2:29 PM, Benjamin Root wrote:
>
>         Yes, those tools do "snarf" up pick events via the widgetlock
>         mechanism,
>         IIRC. This is entirely intentional, and I an not sure there is a bug
>         here to fix.
>
>
>         On Thu, Aug 21, 2014 at 12:01 PM, Thomas Caswell
>         <tca...@gm... <mailto:tca...@gm...>
>         <mailto:tca...@gm... <mailto:tca...@gm...>>> wrote:
>
>              On Thu, Aug 21, 2014 at 9:44 AM, Michael Kaufman
>         <kau...@or... <mailto:kau...@or...>
>              <mailto:kau...@or... <mailto:kau...@or...>>> wrote:
>               >
>               >    # plot axvlines here... etc.
>               >
>               >    global cids
>               >
>               >    # remove any previous connections
>               >    for i in cids:
>               >       gcf().canvas.mpl_disconnect(i)
>               >    cids = []
>               >
>               >
>         cids.append(gcf().canvas.mpl___connect('pick_event',self.__pick))
>               >
>
>         cids.append(gcf().canvas.mpl___connect('button_press_event',__self.click))
>               >
>               >    draw()
>               >
>               > def pick(self, event):
>               >    thisline = event.artist
>               >    xdata, ydata = thisline.get_data()
>               >    print xdata[0]
>               >
>               > def click(self, event):
>               >    print "clicked"
>
>
>              See this minimal example
>
>              ```
>              import matplotlib.pyplot as plt
>              fig, ax = plt.subplots()
>
>              ax.axvline(.5, picker=6)
>              ax.plot(range(3))
>              cids = []
>
>              plt.draw()
>
>              def pick(event):
>                  thisline = event.artist
>                  xdata, ydata = thisline.get_data()
>                  print xdata[0]
>
>              def click(event):
>                  print "clicked"
>
>
>              cids.append(fig.canvas.mpl___connect('pick_event', pick))
>              cids.append(fig.canvas.mpl___connect('button_press_event',
>         click))
>
>              ```
>
>              If you turn the zoom/pan tool off the picker works again.
>         I suspect
>              that there is some logic underneath those tools that are
>         snarfing
>              events when the are turned on to avoid messy conflicts.
>         There is some
>              work going on (MEP22 iirc) to update the toolbar and make
>         our tool
>              handling saner.
>
>              Tom
>              --
>              Thomas Caswell
>         tca...@gm... <mailto:tca...@gm...>
>         <mailto:tca...@gm... <mailto:tca...@gm...>>
>
>
>
>         ------------------------------__------------------------------__------------------
>              Slashdot TV.
>              Video for Nerds.  Stuff that matters.
>         http://tv.slashdot.org/
>              _________________________________________________
>              Matplotlib-users mailing list
>         Matplotlib-users@lists.__sourceforge.net
>         <mailto:Mat...@li...>
>              <mailto:Matplotlib-users@__lists.sourceforge.net
>         <mailto:Mat...@li...>>
>         https://lists.sourceforge.net/__lists/listinfo/matplotlib-__users <https://lists.sourceforge.net/lists/listinfo/matplotlib-users>
>
>
>
>

Imagine someone creates some event that would modify an artist upon
picking, or do some expensive calculation, or some other action. But, I
seriously doubt anybody would want those actions to fire while using the
zoom/pan tool. Especially since the mouse cursor looks totally different. I
am curious why you would expect pick events to fire while using pan/zoom.
What is the user-story that compels that expectation? Perhaps I could be
convinced otherwise to offer some sort of toggle.



On Thu, Aug 21, 2014 at 2:33 PM, Michael Kaufman <kau...@or...> wrote:

> What kind of bad stuff happens if we were to allow that?
>
> M
>
>
> On 8/21/14 2:29 PM, Benjamin Root wrote:
>
>> Yes, those tools do "snarf" up pick events via the widgetlock mechanism,
>> IIRC. This is entirely intentional, and I an not sure there is a bug
>> here to fix.
>>
>>
>> On Thu, Aug 21, 2014 at 12:01 PM, Thomas Caswell <tca...@gm...
>> <mailto:tca...@gm...>> wrote:
>>
>>     On Thu, Aug 21, 2014 at 9:44 AM, Michael Kaufman <kau...@or...
>>     <mailto:kau...@or...>> wrote:
>>      >
>>      >    # plot axvlines here... etc.
>>      >
>>      >    global cids
>>      >
>>      >    # remove any previous connections
>>      >    for i in cids:
>>      >       gcf().canvas.mpl_disconnect(i)
>>      >    cids = []
>>      >
>>      >    cids.append(gcf().canvas.mpl_connect('pick_event',self.pick))
>>      >
>>     cids.append(gcf().canvas.mpl_connect('button_press_event',
>> self.click))
>>      >
>>      >    draw()
>>      >
>>      > def pick(self, event):
>>      >    thisline = event.artist
>>      >    xdata, ydata = thisline.get_data()
>>      >    print xdata[0]
>>      >
>>      > def click(self, event):
>>      >    print "clicked"
>>
>>
>>     See this minimal example
>>
>>     ```
>>     import matplotlib.pyplot as plt
>>     fig, ax = plt.subplots()
>>
>>     ax.axvline(.5, picker=6)
>>     ax.plot(range(3))
>>     cids = []
>>
>>     plt.draw()
>>
>>     def pick(event):
>>         thisline = event.artist
>>         xdata, ydata = thisline.get_data()
>>         print xdata[0]
>>
>>     def click(event):
>>         print "clicked"
>>
>>
>>     cids.append(fig.canvas.mpl_connect('pick_event', pick))
>>     cids.append(fig.canvas.mpl_connect('button_press_event', click))
>>
>>     ```
>>
>>     If you turn the zoom/pan tool off the picker works again.  I suspect
>>     that there is some logic underneath those tools that are snarfing
>>     events when the are turned on to avoid messy conflicts.  There is some
>>     work going on (MEP22 iirc) to update the toolbar and make our tool
>>     handling saner.
>>
>>     Tom
>>     --
>>     Thomas Caswell
>>     tca...@gm... <mailto:tca...@gm...>
>>
>>
>>     ------------------------------------------------------------
>> ------------------
>>     Slashdot TV.
>>     Video for Nerds.  Stuff that matters.
>>     http://tv.slashdot.org/
>>     _______________________________________________
>>     Matplotlib-users mailing list
>>     Mat...@li...
>>     <mailto:Mat...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>
>

What kind of bad stuff happens if we were to allow that?

M

On 8/21/14 2:29 PM, Benjamin Root wrote:
> Yes, those tools do "snarf" up pick events via the widgetlock mechanism,
> IIRC. This is entirely intentional, and I an not sure there is a bug
> here to fix.
>
>
> On Thu, Aug 21, 2014 at 12:01 PM, Thomas Caswell <tca...@gm...
> <mailto:tca...@gm...>> wrote:
>
>     On Thu, Aug 21, 2014 at 9:44 AM, Michael Kaufman <kau...@or...
>     <mailto:kau...@or...>> wrote:
>      >
>      >    # plot axvlines here... etc.
>      >
>      >    global cids
>      >
>      >    # remove any previous connections
>      >    for i in cids:
>      >       gcf().canvas.mpl_disconnect(i)
>      >    cids = []
>      >
>      >    cids.append(gcf().canvas.mpl_connect('pick_event',self.pick))
>      >
>     cids.append(gcf().canvas.mpl_connect('button_press_event',self.click))
>      >
>      >    draw()
>      >
>      > def pick(self, event):
>      >    thisline = event.artist
>      >    xdata, ydata = thisline.get_data()
>      >    print xdata[0]
>      >
>      > def click(self, event):
>      >    print "clicked"
>
>
>     See this minimal example
>
>     ```
>     import matplotlib.pyplot as plt
>     fig, ax = plt.subplots()
>
>     ax.axvline(.5, picker=6)
>     ax.plot(range(3))
>     cids = []
>
>     plt.draw()
>
>     def pick(event):
>         thisline = event.artist
>         xdata, ydata = thisline.get_data()
>         print xdata[0]
>
>     def click(event):
>         print "clicked"
>
>
>     cids.append(fig.canvas.mpl_connect('pick_event', pick))
>     cids.append(fig.canvas.mpl_connect('button_press_event', click))
>
>     ```
>
>     If you turn the zoom/pan tool off the picker works again.  I suspect
>     that there is some logic underneath those tools that are snarfing
>     events when the are turned on to avoid messy conflicts.  There is some
>     work going on (MEP22 iirc) to update the toolbar and make our tool
>     handling saner.
>
>     Tom
>     --
>     Thomas Caswell
>     tca...@gm... <mailto:tca...@gm...>
>
>     ------------------------------------------------------------------------------
>     Slashdot TV.
>     Video for Nerds.  Stuff that matters.
>     http://tv.slashdot.org/
>     _______________________________________________
>     Matplotlib-users mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Yes, those tools do "snarf" up pick events via the widgetlock mechanism,
IIRC. This is entirely intentional, and I an not sure there is a bug here
to fix.


On Thu, Aug 21, 2014 at 12:01 PM, Thomas Caswell <tca...@gm...> wrote:

> On Thu, Aug 21, 2014 at 9:44 AM, Michael Kaufman <kau...@or...>
> wrote:
> >
> >    # plot axvlines here... etc.
> >
> >    global cids
> >
> >    # remove any previous connections
> >    for i in cids:
> >       gcf().canvas.mpl_disconnect(i)
> >    cids = []
> >
> >    cids.append(gcf().canvas.mpl_connect('pick_event',self.pick))
> >    cids.append(gcf().canvas.mpl_connect('button_press_event',self.click))
> >
> >    draw()
> >
> > def pick(self, event):
> >    thisline = event.artist
> >    xdata, ydata = thisline.get_data()
> >    print xdata[0]
> >
> > def click(self, event):
> >    print "clicked"
>
>
> See this minimal example
>
> ```
> import matplotlib.pyplot as plt
> fig, ax = plt.subplots()
>
> ax.axvline(.5, picker=6)
> ax.plot(range(3))
> cids = []
>
> plt.draw()
>
> def pick(event):
>    thisline = event.artist
>    xdata, ydata = thisline.get_data()
>    print xdata[0]
>
> def click(event):
>    print "clicked"
>
>
> cids.append(fig.canvas.mpl_connect('pick_event', pick))
> cids.append(fig.canvas.mpl_connect('button_press_event', click))
>
> ```
>
> If you turn the zoom/pan tool off the picker works again.  I suspect
> that there is some logic underneath those tools that are snarfing
> events when the are turned on to avoid messy conflicts.  There is some
> work going on (MEP22 iirc) to update the toolbar and make our tool
> handling saner.
>
> Tom
> --
> Thomas Caswell
> tca...@gm...
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Thu, Aug 21, 2014 at 9:44 AM, Michael Kaufman <kau...@or...> wrote:
>
>    # plot axvlines here... etc.
>
>    global cids
>
>    # remove any previous connections
>    for i in cids:
>       gcf().canvas.mpl_disconnect(i)
>    cids = []
>
>    cids.append(gcf().canvas.mpl_connect('pick_event',self.pick))
>    cids.append(gcf().canvas.mpl_connect('button_press_event',self.click))
>
>    draw()
>
> def pick(self, event):
>    thisline = event.artist
>    xdata, ydata = thisline.get_data()
>    print xdata[0]
>
> def click(self, event):
>    print "clicked"


See this minimal example

```
import matplotlib.pyplot as plt
fig, ax = plt.subplots()

ax.axvline(.5, picker=6)
ax.plot(range(3))
cids = []

plt.draw()

def pick(event):
   thisline = event.artist
   xdata, ydata = thisline.get_data()
   print xdata[0]

def click(event):
   print "clicked"


cids.append(fig.canvas.mpl_connect('pick_event', pick))
cids.append(fig.canvas.mpl_connect('button_press_event', click))

```

If you turn the zoom/pan tool off the picker works again.  I suspect
that there is some logic underneath those tools that are snarfing
events when the are turned on to avoid messy conflicts.  There is some
work going on (MEP22 iirc) to update the toolbar and make our tool
handling saner.

Tom
-- 
Thomas Caswell
tca...@gm...

Hello,

I am interested in using the Matplotlib transformation framework to
transform a rectangle into a different coordinate system. I am therefore
defining a Rectangle patch and setting the transform to what I want. If
I apply a non-linear transformation, the edges of the rectangle should
no longer necessarily be straight lines. Consider the following example:

---

import numpy as np

import matplotlib.pyplot as plt
from matplotlib.transforms import Affine2D
from matplotlib.patches import Rectangle, Polygon

fig = plt.figure()
ax = fig.add_subplot(1,1,1)

transform = Affine2D().rotate_deg(2) + ax.transData

# Add rectangle
r = Rectangle((0.5,0.5),width=10,height=10,
              transform=transform,
              edgecolor='red', facecolor='none')
ax.add_patch(r)

# Add oversampled rectangle
x = np.array([0.5, 10.5, 10.5, 0.5, 0.5])
y = np.array([0.5, 0.5, 10.5, 10.5, 0.51])
x_i = np.interp(np.linspace(0., 4., 10000), np.arange(5), x)
y_i = np.interp(np.linspace(0., 4., 10000), np.arange(5), y)
p = Polygon(list(zip(x_i, y_i)),
            transform=transform,
            edgecolor='green', facecolor='none')
ax.add_patch(p)

ax.set_xscale('log')
ax.set_yscale('log')

fig.savefig('test.png')

---

The green lines show what I would expect the rectangle to look like, and
the red is what it ends up looking like if I use the Rectangle patch.
What must be happening is that only the vertices of the rectangle get
transformed and then are connected by straight lines.

So my question is, is there a way to make the Rectangle patch behave
like the custom polygon I'm creating here?

Thanks for any advice,

Cheers,
Tom

Hi,

ipython 3.0.0-dev
matplotlib 1.3.1
GTKAgg backend
mac osx 10.9

If I create a pick_event on an axvline (with picker=6), there is no 
problem triggering the pick event the first time the figure is shown (or 
many times if I _don't_ zoom or pan). But if I then zoom in or pan 
(using the toolbar tools) the pick_event function stops triggering.

The button_press_event that I also created still works after 
zooming/panning. The pick_event still doesn't work even if I disconnect 
all the events and recreate them (by creating a new object).
I have to close the figure and make a new one to make the pick work 
again. The button_press_event always works.

This is the bottom of the plotting function:

   # plot axvlines here... etc.

   global cids

   # remove any previous connections
   for i in cids:
      gcf().canvas.mpl_disconnect(i)
   cids = []

   cids.append(gcf().canvas.mpl_connect('pick_event',self.pick))
   cids.append(gcf().canvas.mpl_connect('button_press_event',self.click))

   draw()

def pick(self, event):
   thisline = event.artist
   xdata, ydata = thisline.get_data()
   print xdata[0]

def click(self, event):
   print "clicked"

Anybody got a clue what's going on? Does the Line2D get deleted and 
recreated without the picker enabled?

M

Many thanks!  The 'pad=25' property worked great.

I also tried prepending '\n' to the minor labels but it threw an error
-- I'll confess that I did not try very hard since 'pad=25' worked.

On 08/15/2014 05:28 PM, Thomas Caswell wrote:
> Use the `pad` property which sets how far the tick labels are from the axis.
> 
>     ax1.tick_params(axis='x',which='minor',bottom='off',top='off', pad=25)
> 
> iirc, the units on pad are font-points
> 
> Tom
> 
> On Fri, Aug 15, 2014 at 5:21 PM, Sterling Smith <sm...@fu...> wrote:
>> How about prepending '\n' to your minor labels?
>>
>> On Aug 15, 2014, at 1:38PM, Ted To wrote:
>>
>>> Hi,
>>>
>>> I'm trying to set two lines of xtick_labels But I can't figure out how
>>> to get them on separate lines.  These are for errorbars where I have two
>>> variables for each of four categories.  Using the following code, I'm
>>> able to create the attached figure.  How does one move the "minor"
>>> xtick_labels to a 2nd line?  A minor problem that maybe someone knows
>>> the answer to is, how do I increase the width of the x axis so that
>>> there is some space before and after the first and last ticks?
>>> (ax1.set_xlim(-.5,7.5) does not seem to work.)
>>>
>>> Many thanks,
>>> Ted
>>>
>>> fig,ax1=plt.subplots()
>>> ax1.errorbar(wageAllTypes.index,wageAllTypes['mean'],yerr=wageAllTypes['sd'],fmt='bo')
>>> xticks=[0,1,2,3,4,5,6,7]
>>> xticks_minor=[.5,2.5,4.5,6.5]
>>> ax1.set_xticks(xticks)
>>> ax1.set_xticks(xticks_minor, minor=True)
>>> ax1.set_xticklabels(['All Jobs','Job 1','Job 2','Job 3'],minor=True)
>>> ax1.set_xticklabels([r'$w$',r'$\xi$',r'$w$',r'$\xi$',r'$w$',r'$\xi$',r'$w$',r'$\xi$]')
>>>
>>> ax1.tick_params(axis='x',which='major')
>>> ax1.tick_params(axis='x',which='minor',bottom='off',top='off')
>>> ax1.set_ylabel(r'$\ln w$',ha='right',rotation='horizontal')
>>>
>>> ax2 = ax1.twinx()
>>> ax2.errorbar(xiAllTypes.index,xiAllTypes['mean'],yerr=xiAllTypes['sd'],fmt='ro')
>>> ax2.set_ylabel(r'$\xi$',ha='left',rotation='horizontal')
>>> <figure_1.png>------------------------------------------------------------------------------
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
> 

Use the `pad` property which sets how far the tick labels are from the axis.

    ax1.tick_params(axis='x',which='minor',bottom='off',top='off', pad=25)

iirc, the units on pad are font-points

Tom

On Fri, Aug 15, 2014 at 5:21 PM, Sterling Smith <sm...@fu...> wrote:
> How about prepending '\n' to your minor labels?
>
> On Aug 15, 2014, at 1:38PM, Ted To wrote:
>
>> Hi,
>>
>> I'm trying to set two lines of xtick_labels But I can't figure out how
>> to get them on separate lines.  These are for errorbars where I have two
>> variables for each of four categories.  Using the following code, I'm
>> able to create the attached figure.  How does one move the "minor"
>> xtick_labels to a 2nd line?  A minor problem that maybe someone knows
>> the answer to is, how do I increase the width of the x axis so that
>> there is some space before and after the first and last ticks?
>> (ax1.set_xlim(-.5,7.5) does not seem to work.)
>>
>> Many thanks,
>> Ted
>>
>> fig,ax1=plt.subplots()
>> ax1.errorbar(wageAllTypes.index,wageAllTypes['mean'],yerr=wageAllTypes['sd'],fmt='bo')
>> xticks=[0,1,2,3,4,5,6,7]
>> xticks_minor=[.5,2.5,4.5,6.5]
>> ax1.set_xticks(xticks)
>> ax1.set_xticks(xticks_minor, minor=True)
>> ax1.set_xticklabels(['All Jobs','Job 1','Job 2','Job 3'],minor=True)
>> ax1.set_xticklabels([r'$w$',r'$\xi$',r'$w$',r'$\xi$',r'$w$',r'$\xi$',r'$w$',r'$\xi$]')
>>
>> ax1.tick_params(axis='x',which='major')
>> ax1.tick_params(axis='x',which='minor',bottom='off',top='off')
>> ax1.set_ylabel(r'$\ln w$',ha='right',rotation='horizontal')
>>
>> ax2 = ax1.twinx()
>> ax2.errorbar(xiAllTypes.index,xiAllTypes['mean'],yerr=xiAllTypes['sd'],fmt='ro')
>> ax2.set_ylabel(r'$\xi$',ha='left',rotation='horizontal')
>> <figure_1.png>------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users



-- 
Thomas Caswell
tca...@gm...

How about prepending '\n' to your minor labels?

On Aug 15, 2014, at 1:38PM, Ted To wrote:

> Hi,
> 
> I'm trying to set two lines of xtick_labels But I can't figure out how
> to get them on separate lines.  These are for errorbars where I have two
> variables for each of four categories.  Using the following code, I'm
> able to create the attached figure.  How does one move the "minor"
> xtick_labels to a 2nd line?  A minor problem that maybe someone knows
> the answer to is, how do I increase the width of the x axis so that
> there is some space before and after the first and last ticks?
> (ax1.set_xlim(-.5,7.5) does not seem to work.)
> 
> Many thanks,
> Ted
> 
> fig,ax1=plt.subplots()
> ax1.errorbar(wageAllTypes.index,wageAllTypes['mean'],yerr=wageAllTypes['sd'],fmt='bo')
> xticks=[0,1,2,3,4,5,6,7]
> xticks_minor=[.5,2.5,4.5,6.5]
> ax1.set_xticks(xticks)
> ax1.set_xticks(xticks_minor, minor=True)
> ax1.set_xticklabels(['All Jobs','Job 1','Job 2','Job 3'],minor=True)
> ax1.set_xticklabels([r'$w$',r'$\xi$',r'$w$',r'$\xi$',r'$w$',r'$\xi$',r'$w$',r'$\xi$]')
> 
> ax1.tick_params(axis='x',which='major')
> ax1.tick_params(axis='x',which='minor',bottom='off',top='off')
> ax1.set_ylabel(r'$\ln w$',ha='right',rotation='horizontal')
> 
> ax2 = ax1.twinx()
> ax2.errorbar(xiAllTypes.index,xiAllTypes['mean'],yerr=xiAllTypes['sd'],fmt='ro')
> ax2.set_ylabel(r'$\xi$',ha='left',rotation='horizontal')
> <figure_1.png>------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,

I'm trying to set two lines of xtick_labels But I can't figure out how
to get them on separate lines.  These are for errorbars where I have two
variables for each of four categories.  Using the following code, I'm
able to create the attached figure.  How does one move the "minor"
xtick_labels to a 2nd line?  A minor problem that maybe someone knows
the answer to is, how do I increase the width of the x axis so that
there is some space before and after the first and last ticks?
(ax1.set_xlim(-.5,7.5) does not seem to work.)

Many thanks,
Ted

fig,ax1=plt.subplots()
ax1.errorbar(wageAllTypes.index,wageAllTypes['mean'],yerr=wageAllTypes['sd'],fmt='bo')
xticks=[0,1,2,3,4,5,6,7]
xticks_minor=[.5,2.5,4.5,6.5]
ax1.set_xticks(xticks)
ax1.set_xticks(xticks_minor, minor=True)
ax1.set_xticklabels(['All Jobs','Job 1','Job 2','Job 3'],minor=True)
ax1.set_xticklabels([r'$w$',r'$\xi$',r'$w$',r'$\xi$',r'$w$',r'$\xi$',r'$w$',r'$\xi$]')

ax1.tick_params(axis='x',which='major')
ax1.tick_params(axis='x',which='minor',bottom='off',top='off')
ax1.set_ylabel(r'$\ln w$',ha='right',rotation='horizontal')

ax2 = ax1.twinx()
ax2.errorbar(xiAllTypes.index,xiAllTypes['mean'],yerr=xiAllTypes['sd'],fmt='ro')
ax2.set_ylabel(r'$\xi$',ha='left',rotation='horizontal')

My problem is that I have a curvilinear grid with some velocity data and I'm
trying to so streamplot
of it. I read at documentation that streamplot do not plot uneven grids and
so I googled it and found this website: 
http://www.flannaghan.com/2013/02/23/interpolation
<http://www.flannaghan.com/2013/02/23/interpolation>   that someone solved
the uneven problem with interpolation, but my problem is a quite harder. My
grid is not just uneven, it is curvilinear. This is really important to me
and I would be very thankful for any help.
The example code and the result:

import numpy as np
import matplotlib.pyplot as plt

xx = np.array([[-32.77352506, -32.50517324, -32.30341846, -32.12060867,
-31.99103968],
   [-32.88670112, -32.63078693, -32.42892793, -32.2527705 , -32.11911059],
   [-32.99884749, -32.75419286, -32.55377179, -32.38220417,-32.24664094],
   [-33.10888993, -32.87495033, -32.67707405, -32.50885765,-32.37311971],
   [-33.2179889 , -32.99317728, -32.79848554, -32.63304009,-32.49815164],
   [-33.32651265, -33.10917094, -32.91791567, -32.75496914,-32.62146004],
   [-33.43449219, -33.22321261, -33.03537769, -32.87477271,-32.74286757],
   [-33.54184645, -33.33551502, -33.15092328, -32.99252837,-32.86227065],
   [-33.64847256, -33.44622558, -33.26461466, -33.1082882 ,-32.97961644],
   [-33.7542787 , -33.55544297, -33.37651245, -33.22209182,-33.09488502],
   [-33.85919362, -33.66323316, -33.48667092, -33.33397251,-33.20807667],
   [-33.96316738, -33.76964127, -33.59513666, -33.44395994,-33.31920308],
   [-34.06616899, -33.87469962, -33.70194888, -33.55208114,-33.42828168],
   [-34.16818354, -33.97843289, -33.80714029, -33.6583608 , -33.5353318 ],
   [-34.26920936, -34.08086103, -33.91073804, -33.76282129,-33.64037232],
   [-34.36925566, -34.18200076, -34.01276449, -33.86548266,-33.74342012],
   [-34.46834041, -34.28186594, -34.11323791, -33.96636282,-33.84448915],
   [-34.56648851, -34.38046701, -34.21217281, -34.06547784,-33.94358994],
   [-34.66372971, -34.4778096 , -34.30958029, -34.16284263, -34.0407292 ],
   [-34.76009619, -34.57389229, -34.40546833, -34.2584719 ,-34.13590974],
   [-34.85561889, -34.66870332, -34.49984222, -34.35238178,-34.22913045],
   [-34.95032165, -34.76221629, -34.59270529, -34.44459209,-34.32038648],
   [-35.04421102, -34.85438466, -34.6840602 , -34.5351297 ,-34.40966975],
   [-35.13725786, -34.94513595, -34.77391107, -34.62403315,-34.49697031],
   [-35.22936336, -35.03436723, -34.86226647, -34.7113589 , -34.5822793 ],
   [-35.3202956 , -35.12194712, -34.9491432 , -34.79718943,-34.66559567],
   [-35.40957149, -35.20773648, -35.03457067, -34.88164276,-34.74693998],
   [-35.49624617, -35.29165455, -35.11859869, -34.96488179,-34.82637986],
   [-35.57858891, -35.3738341 , -35.20134195, -35.04711944,-34.90406862],
   [-35.65407127, -35.45484625, -35.28327484, -35.12861303,-34.98028311]])


yy = np.array([[-11.3529916 , -10.83017948, -10.36062676, 
-9.85499224,-9.36742115],
   [-11.24914312, -10.77486528, -10.30767657,  -9.81790781,-9.33347811],
   [-11.16896123, -10.71827884, -10.25654788,  -9.77873607,-9.29985941],
   [-11.09864806, -10.66157581, -10.20688907,  -9.7389486 ,-9.26669158],
   [-11.03379175, -10.60554773, -10.15836065,  -9.69919353,  -9.2340536 ],
   [-10.97234269, -10.55056628, -10.11076275,  -9.65973621,-9.20197376],
   [-10.91318741, -10.49672964, -10.06398502,  -9.62068888,-9.17044015],
   [-10.85567682, -10.44399733, -10.01795592,  -9.58209354,-9.13941538],
   [-10.79941292, -10.39227109,  -9.97261586,  -9.54395471,-9.10884902],
   [-10.74413933, -10.3414354 ,  -9.92790608,  -9.50625469,-9.07868586],
   [-10.68968138, -10.29137538,  -9.88376528,  -9.46896173,-9.04887037],
   [-10.63591212, -10.24198327,  -9.84012944,  -9.43203502,-9.01934878],
   [-10.58273238, -10.19315956,  -9.79693259,  -9.39542787,-8.99006955],
   [-10.53005851, -10.14481189,  -9.75410767,  -9.35908973,-8.96098324],
   [-10.47781454, -10.09685326,  -9.71158727,  -9.32296761,-8.93204187],
   [-10.42592671, -10.04920008,  -9.66930413,  -9.28700687,-8.90319822],
   [-10.37431922, -10.00177041,  -9.62719161,  -9.25115173,  -8.874405  ],
   [-10.32291042,  -9.95448254,  -9.5851842 ,  -9.21534553,-8.84561388],
   [-10.27160885,  -9.90725399,  -9.54321824,  -9.17953081,  -8.8167744 ],
   [-10.22030865,  -9.86000117,  -9.50123304,  -9.1436493 ,-8.78783251],
   [-10.16888358,  -9.81263985,  -9.45917264,  -9.10764179,-8.75872859],
   [-10.11717908,  -9.7650871 ,  -9.41698825,  -9.07144794,-8.72939466],
   [-10.06500151,  -9.71726547,  -9.37464171,  -9.03500603,-8.69975035],
   [-10.01210356,  -9.66911062,  -9.33211024,  -8.99825263,-8.66969694],
   [ -9.95816574,  -9.62058406,  -9.28939255,  -8.96112225,  -8.639109  ],
   [ -9.90277604,  -9.57169217,  -9.24651752,  -8.92354679,-8.60782312],
   [ -9.84541584,  -9.52250952,  -9.2035585 ,  -8.88545441,-8.57562469],
   [ -9.78546516,  -9.4731919 ,  -9.1606645 ,  -8.84676681,-8.54223813],
   [ -9.72217224,  -9.42392909,  -9.11814094,  -8.80739381,-8.50733329],
   [ -9.65407127,  -9.37474785,  -9.07654968,  -8.76722606,-8.47056622]])



u =  3*np.cos(xx)*(-3)*np.sin(yy)
v = 2*np.sin(xx)*3*np.cos(yy)
speed = np.sqrt((u**2)+(v**2))

plt.ion()
fig,(ax1,ax2) = plt.subplots(1,2,figsize=(14,8))

ax1.contourf(xx,yy,speed)
ax1.plot(xx,yy,'-k',alpha=0.3)
ax1.plot(xx.T,yy.T,'-k',alpha=0.3)
ax1.quiver(xx,yy,u,v)


ax2.contourf(xx,yy,speed)
ax2.plot(xx,yy,'-k',alpha=0.3)
ax2.plot(xx.T,yy.T,'-k',alpha=0.3)
ax2.streamplot(xx,yy,u,v)


<http://matplotlib.1069221.n5.nabble.com/file/n43795/error.png> 



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Streamplot-for-Uneven-Curvilinear-Grid-tp43795.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hello,

I build RPMs to distribute matplotlib to our local RedHat 6 machines.
The procedure I use is simply

    python setup.py bdist_rpm

This works fine until I attempt to include gtk support.  The problem
is that the bdist_rpm procedure creates a temporary shell script file
which unset's the $DISPLAY variable.  This then causes setupext.py's
'import gtk' to fail due to not having $DISPLAY set and the build then
happens without gtk support.  If I hard code it in setup.cfg backend
section to True, then the build fails completely (as it should).

Am I missing something obvious to work around this?

daryl

Thanks for your insights, Ian! 

A somewhat slower trifinder which requires less memory might be even faster in the end as creating the trifinder itself takes a lot of time (almost a minute in our case). 

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu

> -----Original Message-----
> From: Ian Thomas [mailto:ian...@gm...]
> Sent: Tuesday, August 12, 2014 4:35 AM
> To: Hartmut Kaiser
> Cc: Andrew Dawson; Carola Kaiser; matplotlib-users
> Subject: Re: [Matplotlib-users] Crash when using
> matplotlib.tri.LinearTriInterpolator
> 
> Here are the results of my investigation.  There is probably more
> information here than anyone else wants, but it is useful information for
> future improvements.
> 
> Most of the RAM is taken up by a trifinder object which is at the heart of
> a triinterpolator, and is used to find the triangles of a Triangulation in
> which (x,y) points lie.  The code
>     interp = tri.LinearTriInterpolator(triang, data)
> is equivalent to
>     trifinder = tri.TrapezoidMapTriFinder(triang)
>     interp = tri.LinearTriInterpolator(triang, data, trifinder=trifinder)
> 
> Using the latter with memory_profiler
> (https://pypi.python.org/pypi/memory_profiler) indicates that this is
> where most of the RAM is being used.  Here are some figures for trifinder
> RAM usage as a function of ntri, the number of triangles in the
> triangulation:
> 
> ntri   trifinder MB
> ----   ------------
> 1000         26
> 10000        33
> 100000      116
> 1000000     912
> 2140255    1936
> 
> The RAM usage is less than linear in ntri, but clearly too much for large
> triangulations unless you have a lot of RAM.
> 
> The trifinder precomputes a tree of nodes to make looking up triangles
> quick.  Searching through 2 million triangles in an ad-hoc manner would be
> very slow; the trifinder is very fast in comparison.  Here are some stats
> for the tree that trifinder uses (the columns are number of nodes in the
> tree, maximum node depth, and mean node depth):
>    ntri      nodes  max depth  mean depth
> -------  ---------  ---------  ----------
>    1000     179097      37        23.24
>   10000    3271933      53        30.74
>  100000   36971309      69        37.15
> 1000000  853117229      87        48.66
> The mean depth is the mean number of nodes that have to be traversed to
> find a triangle, and the max depth is the worst case.  The search time is
> therefore O(log ntri).
> The triangle interpolator code is structured in such a way that it is easy
> to plug in a different trifinder if the default one isn't appropriate.  At
> the moment there is only the one available however
> (TrapezoidMapTriFinder).  For the problem at hand, a trifinder that is
> slower but consumes less RAM would be preferable.  There are various
> possibilities, they just have to be implemented!  I will take a look at it
> sometime, but it probably will not be soon.
> Ian Thomas

Here are the results of my investigation.  There is probably more
information here than anyone else wants, but it is useful information for
future improvements.

Most of the RAM is taken up by a trifinder object which is at the heart of
a triinterpolator, and is used to find the triangles of a Triangulation in
which (x,y) points lie.  The code

    interp = tri.LinearTriInterpolator(triang, data)

is equivalent to

    trifinder = tri.TrapezoidMapTriFinder(triang)
    interp = tri.LinearTriInterpolator(triang, data, trifinder=trifinder)

Using the latter with memory_profiler (
https://pypi.python.org/pypi/memory_profiler) indicates that this is where
most of the RAM is being used.  Here are some figures for trifinder RAM
usage as a function of ntri, the number of triangles in the triangulation:

ntri   trifinder MB
----   ------------
1000         26
10000        33
100000      116
1000000     912
2140255    1936

The RAM usage is less than linear in ntri, but clearly too much for large
triangulations unless you have a lot of RAM.

The trifinder precomputes a tree of nodes to make looking up triangles
quick.  Searching through 2 million triangles in an ad-hoc manner would be
very slow; the trifinder is very fast in comparison.  Here are some stats
for the tree that trifinder uses (the columns are number of nodes in the
tree, maximum node depth, and mean node depth):

   ntri      nodes  max depth  mean depth
-------  ---------  ---------  ----------
   1000     179097      37        23.24
  10000    3271933      53        30.74
 100000   36971309      69        37.15
1000000  853117229      87        48.66

The mean depth is the mean number of nodes that have to be traversed to
find a triangle, and the max depth is the worst case.  The search time is
therefore O(log ntri).

The triangle interpolator code is structured in such a way that it is easy
to plug in a different trifinder if the default one isn't appropriate.  At
the moment there is only the one available however
(TrapezoidMapTriFinder).  For the problem at hand, a trifinder that is
slower but consumes less RAM would be preferable.  There are various
possibilities, they just have to be implemented!  I will take a look at it
sometime, but it probably will not be soon.

Ian Thomas

> > I ran the example on my machine (which is a 64-bit Linux box with 8 GB
> of
> > RAM; Python 2.7, matplotlib 1.3.1) and it runs fine. However, it does
> use
> > around 2 GB of memory, perhaps slightly more. I think the memory usage
> > might be a problem for you if you are using 32-bit Windows. I'm not
> > familiar with the details but I believe the memory available to a single
> > 32-bit process on Win32 may be only 2 GB. I'm also not familiar with the
> > data you provided, but is it possible to reduce to number of points in
> > order to test if memory limitations are the underlying problemhere?
> 
> Nod, your suspicion is correct. The python interpreter bails out once the
> memory footprint reaches 2GBytes. That leaves us with the question if this
> is a quality of implementation issue - using up 2GBytes of main memory for
> 1 million node elements seems to be a bit excessive...
> 
> Thanks everybody for verifying anyways!

Just to round that issue up - I tried running this using Python 2.7 (64Bit) and it does not crash anymore. The memory requirement grows up to almost 4GByte. 

I will verify whether I can get the results I hope for and will report back.

Thanks again!
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu

> 
> Regards Hartmut
> ---------------
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> >
> >
> >
> > On 11 August 2014 14:54, Hartmut Kaiser <har...@gm...>
> wrote:
> > Ian,
> >
> > > I'm running into a crash while trying to construct a
> > > tri.LinearTriInterpolator. Here is the short version of the code:
> > >
> > >     import netCDF4
> > >     import matplotlib.tri as tri
> > >
> > >     var = netCDF4.Dataset('filename.cdf').variables
> > >     x = var['x'][:]
> > >     y = var['y'][:]
> > >     data = var['zeta_max'][:]
> > >     elems = var['element'][:, :]-1
> > >
> > >     triang = tri.Triangulation(x, y, triangles=elems)
> > >
> > >     # this crashes the python interpreter
> > >     interp = tri.LinearTriInterpolator(triang, data)
> > >
> > > The data arrays (x, y, data, elems) are fairly large (>1 mio
> elements),
> > > all
> > > represented as numpy arrays (as returned by netCDF4). The 'data' array
> > is
> > > a
> > > masked array and contains masked values.
> > >
> > > If somebody cares, I'd be able to post a link to the netCDF data file
> > > causing this.
> > >
> > > All this happens when using matplotlib 1.3.1, Win32, Python 2.7.
> > >
> > > Any help would be highly appreciated!
> > > Regards Hartmut
> > >
> > > Hartmut,
> > > That is an excellent issue report; all the relevant information and
> > > nothing extraneous.  Hence the quick response.
> > > The second argument to TriLinearInterpolator (and other
> TriInterpolator
> > > classes), i.e. your 'data' array, is expected to be an array of the
> same
> > > size as the 'x' and 'y' arrays.  It is not expecting a masked
> array.  If
> > a
> > > masked array is used the mask will be ignored, and so the values
> behind
> > > the mask will be used as though they were real values.  If my memory
> of
> > > netCDF is correct, this will be whatever 'FillValue' is defined for
> the
> > > file, but it may depend on what is used to generate the netCDF file.
> > > I would normally expect the code to work but produce useless
> output.  A
> > > crash is possible though.  It would be best if you could post a link
> to
> > > the netCDF file and I will take a closer look to check there is not
> > > something else going wrong.
> > Thanks for the quick response!
> >
> > Here is the data file: http://tinyurl.com/ms7vzxw. I did some more
> > experiments. The picture stays unchanged, even if I fill the masked
> values
> > in the array with some real numbers (I'm not saying that this would give
> > me any sensible results...):
> >
> >     import netCDF4
> >     import matplotlib.tri as tri
> >     var = netCDF4.Dataset('maxele.63.nc').variables
> >     x = var['x'][:]
> >     y = var['y'][:]
> >     data = var['zeta_max'][:]
> >     elems = var['element'][:, :]-1
> >
> >     triang = tri.Triangulation(x, y, triangles=elems)
> >     data = data.filled(0.0)
> >
> >     # this still crashes the python interpreter
> >     interp = tri.LinearTriInterpolator(triang, data)
> >
> > Thanks again!
> > Regards Hartmut
> > ---------------
> > http://boost-spirit.com
> > http://stellar.cct.lsu.edu
> >
> >
> >
> > ------------------------------------------------------------------------
> --
> > ----
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
> >
> >
> > --
> > Dr Andrew Dawson
> > Atmospheric, Oceanic & Planetary Physics
> > Clarendon Laboratory
> > Parks Road
> > Oxford OX1 3PU, UK
> > Tel: +44 (0)1865 282438
> > Email: da...@at...
> > Web Site: http://www2.physics.ox.ac.uk/contacts/people/dawson

Andrew,

> I ran the example on my machine (which is a 64-bit Linux box with 8 GB of
> RAM; Python 2.7, matplotlib 1.3.1) and it runs fine. However, it does use
> around 2 GB of memory, perhaps slightly more. I think the memory usage
> might be a problem for you if you are using 32-bit Windows. I'm not
> familiar with the details but I believe the memory available to a single
> 32-bit process on Win32 may be only 2 GB. I'm also not familiar with the
> data you provided, but is it possible to reduce to number of points in
> order to test if memory limitations are the underlying problemhere?

Nod, your suspicion is correct. The python interpreter bails out once the memory footprint reaches 2GBytes. That leaves us with the question if this is a quality of implementation issue - using up 2GBytes of main memory for 1 million node elements seems to be a bit excessive...

Thanks everybody for verifying anyways!

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu

> 
> 
> 
> On 11 August 2014 14:54, Hartmut Kaiser <har...@gm...> wrote:
> Ian,
> 
> > I'm running into a crash while trying to construct a
> > tri.LinearTriInterpolator. Here is the short version of the code:
> >
> >     import netCDF4
> >     import matplotlib.tri as tri
> >
> >     var = netCDF4.Dataset('filename.cdf').variables
> >     x = var['x'][:]
> >     y = var['y'][:]
> >     data = var['zeta_max'][:]
> >     elems = var['element'][:, :]-1
> >
> >     triang = tri.Triangulation(x, y, triangles=elems)
> >
> >     # this crashes the python interpreter
> >     interp = tri.LinearTriInterpolator(triang, data)
> >
> > The data arrays (x, y, data, elems) are fairly large (>1 mio elements),
> > all
> > represented as numpy arrays (as returned by netCDF4). The 'data' array
> is
> > a
> > masked array and contains masked values.
> >
> > If somebody cares, I'd be able to post a link to the netCDF data file
> > causing this.
> >
> > All this happens when using matplotlib 1.3.1, Win32, Python 2.7.
> >
> > Any help would be highly appreciated!
> > Regards Hartmut
> >
> > Hartmut,
> > That is an excellent issue report; all the relevant information and
> > nothing extraneous.  Hence the quick response.
> > The second argument to TriLinearInterpolator (and other TriInterpolator
> > classes), i.e. your 'data' array, is expected to be an array of the same
> > size as the 'x' and 'y' arrays.  It is not expecting a masked array.  If
> a
> > masked array is used the mask will be ignored, and so the values behind
> > the mask will be used as though they were real values.  If my memory of
> > netCDF is correct, this will be whatever 'FillValue' is defined for the
> > file, but it may depend on what is used to generate the netCDF file.
> > I would normally expect the code to work but produce useless output.  A
> > crash is possible though.  It would be best if you could post a link to
> > the netCDF file and I will take a closer look to check there is not
> > something else going wrong.
> Thanks for the quick response!
> 
> Here is the data file: http://tinyurl.com/ms7vzxw. I did some more
> experiments. The picture stays unchanged, even if I fill the masked values
> in the array with some real numbers (I'm not saying that this would give
> me any sensible results...):
> 
>     import netCDF4
>     import matplotlib.tri as tri
>     var = netCDF4.Dataset('maxele.63.nc').variables
>     x = var['x'][:]
>     y = var['y'][:]
>     data = var['zeta_max'][:]
>     elems = var['element'][:, :]-1
> 
>     triang = tri.Triangulation(x, y, triangles=elems)
>     data = data.filled(0.0)
> 
>     # this still crashes the python interpreter
>     interp = tri.LinearTriInterpolator(triang, data)
> 
> Thanks again!
> Regards Hartmut
> ---------------
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> 
> --------------------------------------------------------------------------
> ----
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
> 
> 
> --
> Dr Andrew Dawson
> Atmospheric, Oceanic & Planetary Physics
> Clarendon Laboratory
> Parks Road
> Oxford OX1 3PU, UK
> Tel: +44 (0)1865 282438
> Email: da...@at...
> Web Site: http://www2.physics.ox.ac.uk/contacts/people/dawson