Re: [matplotlib-devel] Replacing matplotlib.delaunay natural neighbor interpolation
Hi Nathan, To deal with your immediate problem of not wanting to see the deprecation warnings you can continue to use matplotlib.delaunay and suppress the warnings using e.g. http://docs.python.org/2/library/warnings.html#temporarily-suppressing-warnings. This will be OK for a year or two, but eventually we will completely remove matplotlib.delaunay. It will however give you time to come up with a solution. The short answer is 1) replace all use of matplotlib.delaunay.Triangulation with matplotlib.tri.Triangulation, and 2) use some other form of interpolation than natural neighbour! Matplotlib has linear and cubic triangular grid interpolators ( http://matplotlib.org/dev/api/tri_api.html); if these are acceptable your code changes should be minimal. scipy.interpolate has a few more options (but no natural neighbour) which will be a little more work. Even if you were to like the natgrid approach I would steer you away from it as I can see us removing it completely from matplotlib sometime in the future. Alternatively you could incorporate the matplotlib.delaunay code into your project and hence carry on using it as you are, but this would be madness as you would have to deal with the building of a C python extension, plus the delaunay code is 'not very robust'. You will no doubt have observed this to be the case, and it is the reason why matplotlib and scipy have moved away from it to use qhull instead. I expect we will add more triangular grid interpolators to matplotlib in due course and I am happy to receive suggestions on this. However, this will not include natural neighbour. Natural neighbour interpolation is specific to delaunay triangulation, and as we also support user-specified triangulations I am only interested in interpolation that covers all triangulations. I hope this has been of some help, but I fear not... Ian Thomas -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP22 doc
@tacaswell I modified the wiki reflecting the changes and trying to answer the questions. Please let me know if I answered your questions/concerns. We can iterate as muchs as needed on this, I have no problem modifying the names or functionnality. Sorry for the long email Here a list of things that I changed ToolBase description = '': Small description of the tool persistent = False: If True, the instance of the Tool is registered with Navigation for reuse. This is needed because some tools are keept alive in the background, for example SubplotTool. position = None: Where is it positionned in the toolbar?. -1 = at the end, None = Not in the toolbar. The default tools are all ordered by their position in the Navigation _default_tools array. This argument is mainly used by User created tools that are added after the Toolbar creation. My idea was that for the user created tools, the user could set the position without having to subclass the Navigation class. So this information has to be included in the Tool. activate(self, event): This is the main method of the Tool, it is called when the Tool is triggered by: * Toolbar button click * keypress associated with the Tool Keymap * Call to navigation.click_tool(name) ToolPersistentBase unregister(self, *args): ... Because ToolBase is intened for single use, there is no need of registration for the instances, persistent tools, need to be registered so __init__ is called only onece during the first trigger NavigationBase locks I tend to agree with you. The idea that I had in mind, and maybe was more complex than expected. Was to redirect the events to the tool without need to call the mpl_connect within the tool. So I provided the methods to handle those events directly. This is also from the idea that if we implement the MultiFigureManager, when there is a change on the 'active_figure' Navigation knows about the change and changes the event handlers, in this case the Tools don't need to do anything. It was just to simplify the Tool creation eliminating the need for basic event connection in case of figure changes. Even if we remove the locks we need two locks: canvaslock (for the input) keypress lock, to give the tool the option to absorb the keypress completely. (Tool for anotations comes to mind) I didn't remove the comment for the locks, because I am not sure what is the best option. ToolbarBase I tried to clarify the use of the methods. Most of the methods that you mentionned, are for internal use only but are mandatory for backend implementation. Also I updated the wiki with the "_" that was missing from the private methods. On Mon, Jan 27, 2014 at 9:12 PM, Thomas A Caswell wrote: > I left some comments on the wiki (in []). Not sure what the best way > to leave comments is. > > On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza > wrote: >> Hello everybody >> >> I just added "click_tool" to simulate a click programatically. >> https://github.com/matplotlib/matplotlib/pull/2759 >> >> Is there anything missing or that you want to change? >> I'm saturated so I don't see anything anymore. >> >> I would like to have some input specially in the `ToolbarBase` class. >> I am ready to start the implementation on the other backends, and this >> is the "new class" that have to be implemented for all the backends. >> `Navigation` is mostly copy paste from existing toolbar >> >> Thanks >> Federico >> >> On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson wrote: >>> Hi Federico, >>> >>> I just wanted to say that I've been a little busy lately, but your MEP is >>> really shaping up - I really like the concepts that are being proposed and >>> think it will make a huge difference to people who want to implement custom >>> UIs. >>> >>> Keep up the great work, and continue trying to get feedback from all of us >>> on this! >>> >>> Thanks, >>> >>> Phil >>> >>> >>> On 24 January 2014 18:43, Federico Ariza wrote: Hello everybody I just added some documentation for the MEP22 new classes and methods. Please take a look https://github.com/matplotlib/matplotlib/pull/2759 I ran into some problems, when trying to decide if some methods where public or not. If the method was used only for backend implementation pourposes I put it as private (name starts with underscore) but still documented them in the Notes section of the class. I don't know if this is the correct way to do it, but I couldn't decide. If you prefer any other way to do it, please let me know. Thank you Federico -- Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? -- Antonio Alducin -- -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In B
Re: [matplotlib-devel] MEP22 doc
Hello again
I have been playing with the locks to find a solution.
What we need is a way to let tools absorb the events (lock its use).
The problem that I'm facing is that Navigation itself needs to capture
two different events.
key_press_event for tool triggering
motion_notify_event for setting the message with the pointer position
and cursor changing.
Now the options that I see are:
Let the tools disconnect and reconnect this signals in navigation.
self.figure.canvas.mpl_disconnect(self.navigation.id_move)
self.navigation.id_move =
self.figure.canvas.mpl_connect('motion_notify_event',
self.navigation.mouse_move)
Create helper methods to disconnect and reconnect this signals in navigation
self.navigation.disconnect('mouse_move')
self.navigation.connect('mouse_move')
Use locks and let navigation redirect these events to the appropiate
place (what I'm doing right now).
self.navigation.movelock(self)
self.navigation.movelock.release(self)
Do you see other options?
One thing that is clear, is that for the moment Navigation needs only
two handlers, so I can reduce the number of locks to two
Thanks
Federico
On Tue, Jan 28, 2014 at 11:05 AM, Federico Ariza
wrote:
> @tacaswell I modified the wiki reflecting the changes and trying to
> answer the questions.
> Please let me know if I answered your questions/concerns. We can
> iterate as muchs as needed on this, I have no problem modifying the
> names or functionnality.
>
> Sorry for the long email
> Here a list of things that I changed
>
> ToolBase
> description = '': Small description of the tool
>
> persistent = False: If True, the instance of the Tool is registered
> with Navigation for reuse.
> This is needed because some tools are keept alive in the background,
> for example SubplotTool.
>
> position = None: Where is it positionned in the toolbar?. -1 = at the
> end, None = Not in the toolbar.
> The default tools are all ordered by their position in the Navigation
> _default_tools array. This argument is mainly used by User created
> tools that are added after the Toolbar creation.
> My idea was that for the user created tools, the user could set the
> position without having to subclass the Navigation class.
> So this information has to be included in the Tool.
>
>
> activate(self, event): This is the main method of the Tool, it is
> called when the Tool is triggered by:
> * Toolbar button click
> * keypress associated with the Tool Keymap
> * Call to navigation.click_tool(name)
>
>
> ToolPersistentBase
> unregister(self, *args): ... Because ToolBase is intened for single
> use, there is no need of registration for the instances, persistent
> tools, need to be registered so __init__ is called only onece during
> the first trigger
>
>
> NavigationBase
> locks I tend to agree with you.
> The idea that I had in mind, and maybe was more complex than expected.
> Was to redirect the events to the tool without need to call the
> mpl_connect within the tool. So I provided the methods to handle those
> events directly.
> This is also from the idea that if we implement the
> MultiFigureManager, when there is a change on the 'active_figure'
> Navigation knows about the change and changes the event handlers, in
> this case the Tools don't need to do anything.
> It was just to simplify the Tool creation eliminating the need for
> basic event connection in case of figure changes.
>
> Even if we remove the locks we need two locks:
> canvaslock (for the input)
> keypress lock, to give the tool the option to absorb the keypress
> completely. (Tool for anotations comes to mind)
>
> I didn't remove the comment for the locks, because I am not sure what
> is the best option.
>
>
> ToolbarBase
> I tried to clarify the use of the methods. Most of the methods that
> you mentionned, are for internal use only but are mandatory for
> backend implementation.
> Also I updated the wiki with the "_" that was missing from the private
> methods.
>
> On Mon, Jan 27, 2014 at 9:12 PM, Thomas A Caswell
> wrote:
>> I left some comments on the wiki (in []). Not sure what the best way
>> to leave comments is.
>>
>> On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza
>> wrote:
>>> Hello everybody
>>>
>>> I just added "click_tool" to simulate a click programatically.
>>> https://github.com/matplotlib/matplotlib/pull/2759
>>>
>>> Is there anything missing or that you want to change?
>>> I'm saturated so I don't see anything anymore.
>>>
>>> I would like to have some input specially in the `ToolbarBase` class.
>>> I am ready to start the implementation on the other backends, and this
>>> is the "new class" that have to be implemented for all the backends.
>>> `Navigation` is mostly copy paste from existing toolbar
>>>
>>> Thanks
>>> Federico
>>>
>>> On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson wrote:
Hi Federico,
I just wanted to say that I've been a little busy lately, but your MEP is
really shaping up - I really like the concepts that are bei
Re: [matplotlib-devel] MEP22 doc
@tacaswell regarding your last comments on the wiki
Again, please let me know if something is not clear or you have suggestions
Again, sorry for the long email, but please don't forget the previous
one about the locks.
activate: I agree with you, renamed to trigger
[I don't understand. The `__init__` gets called when the tool object
is created (and it gets registered with a particular
`NavigationBase`/`Figure`/`canvas`. The tool object then sits around
doing nothing waiting to be triggered. I can see wanting to remove
one of these buttons, in which case it will need to be un-registered]
I am not expressing myself correctly, what I am trying to say is that
the Tool object is only created when the tool is triggered.
The tool.trigger method is called in the ToolBase.__init__ method
For ToolBase tools, the object is not registered, so there is no
reference to it anywhere, so it should be garbage collected. I can add
a del to the object but I think is unnecesary.
ToolPersistentBase
[shouldn't `__init__` be called when the tool is created?
I think the confusion here is that I don't create the tools until they
are triggered, until then, is just a reference to the class. in the
navitaion._tools dict.
ToolToggleBase
[I would give them enable/disable methods, and make their `triggered`
action to call their own `enable`]
Actually it makes more sense, thanks.
On Tue, Jan 28, 2014 at 6:17 PM, Federico Ariza
wrote:
> Hello again
>
> I have been playing with the locks to find a solution.
> What we need is a way to let tools absorb the events (lock its use).
>
> The problem that I'm facing is that Navigation itself needs to capture
> two different events.
>
> key_press_event for tool triggering
> motion_notify_event for setting the message with the pointer position
> and cursor changing.
>
> Now the options that I see are:
>
> Let the tools disconnect and reconnect this signals in navigation.
> self.figure.canvas.mpl_disconnect(self.navigation.id_move)
>
> self.navigation.id_move =
> self.figure.canvas.mpl_connect('motion_notify_event',
> self.navigation.mouse_move)
>
> Create helper methods to disconnect and reconnect this signals in navigation
> self.navigation.disconnect('mouse_move')
>
> self.navigation.connect('mouse_move')
>
> Use locks and let navigation redirect these events to the appropiate
> place (what I'm doing right now).
> self.navigation.movelock(self)
> self.navigation.movelock.release(self)
>
> Do you see other options?
>
> One thing that is clear, is that for the moment Navigation needs only
> two handlers, so I can reduce the number of locks to two
>
> Thanks
> Federico
>
> On Tue, Jan 28, 2014 at 11:05 AM, Federico Ariza
> wrote:
>> @tacaswell I modified the wiki reflecting the changes and trying to
>> answer the questions.
>> Please let me know if I answered your questions/concerns. We can
>> iterate as muchs as needed on this, I have no problem modifying the
>> names or functionnality.
>>
>> Sorry for the long email
>> Here a list of things that I changed
>>
>> ToolBase
>> description = '': Small description of the tool
>>
>> persistent = False: If True, the instance of the Tool is registered
>> with Navigation for reuse.
>> This is needed because some tools are keept alive in the background,
>> for example SubplotTool.
>>
>> position = None: Where is it positionned in the toolbar?. -1 = at the
>> end, None = Not in the toolbar.
>> The default tools are all ordered by their position in the Navigation
>> _default_tools array. This argument is mainly used by User created
>> tools that are added after the Toolbar creation.
>> My idea was that for the user created tools, the user could set the
>> position without having to subclass the Navigation class.
>> So this information has to be included in the Tool.
>>
>>
>> activate(self, event): This is the main method of the Tool, it is
>> called when the Tool is triggered by:
>> * Toolbar button click
>> * keypress associated with the Tool Keymap
>> * Call to navigation.click_tool(name)
>>
>>
>> ToolPersistentBase
>> unregister(self, *args): ... Because ToolBase is intened for single
>> use, there is no need of registration for the instances, persistent
>> tools, need to be registered so __init__ is called only onece during
>> the first trigger
>>
>>
>> NavigationBase
>> locks I tend to agree with you.
>> The idea that I had in mind, and maybe was more complex than expected.
>> Was to redirect the events to the tool without need to call the
>> mpl_connect within the tool. So I provided the methods to handle those
>> events directly.
>> This is also from the idea that if we implement the
>> MultiFigureManager, when there is a change on the 'active_figure'
>> Navigation knows about the change and changes the event handlers, in
>> this case the Tools don't need to do anything.
>> It was just to simplify the Tool creation eliminating the need for
>> basic event connection in case of figure changes.
>>
>> Even if we remove
Re: [matplotlib-devel] MEP22 doc
On Tue, Jan 28, 2014 at 7:27 PM, Federico Ariza wrote: > activate: I agree with you, renamed to trigger > > [I don't understand. The `__init__` gets called when the tool object > is created (and it gets registered with a particular > `NavigationBase`/`Figure`/`canvas`. The tool object then sits around > doing nothing waiting to be triggered. I can see wanting to remove > one of these buttons, in which case it will need to be un-registered] > > I am not expressing myself correctly, what I am trying to say is that > the Tool object is only created when the tool is triggered. > The tool.trigger method is called in the ToolBase.__init__ method > For ToolBase tools, the object is not registered, so there is no > reference to it anywhere, so it should be garbage collected. I can add > a del to the object but I think is unnecesary. > ToolPersistentBase > [shouldn't `__init__` be called when the tool is created? > I think the confusion here is that I don't create the tools until they > are triggered, until then, is just a reference to the class. in the > navitaion._tools dict. If you do not instantiate the object until the button get pushed, why even bother with a class, can't this just be a function? I still think it would be better create the `Tool` objects when you create the figure and then call their `trigger` function when the button gets pushed. For one thing, this makes it dead-simple to rig up the gui side of things (at least in Qt, I would assume the others are similar `button.clicked.connect(self._home_tool.trigger)` ) as the functions we care about already look like call-backs. I am not sure that the benefit of doing it the way you wrote it (with the button-push-time object creation) is worth the added complexity. I think we only need two kinds of tools, the kind you push once and they fire off an action (simple push button, need one public function `trigger` this works for simple actions home, quit, back and things that create extra windows) and the kind you can toggle on and off (need two public functions `enable` and `disable` which are what they do when you turn them on (set up call backs to grab input) and turn them off (tear down/disconnect the canvas call backs) which eliminates much of the need for keeping track of locks (I think). The toggle kind may or may not be group in to exclusion groups (pan/zoom) but I could see doing 'toggle grid lines' as this type as well. Tom -- Thomas Caswell tcasw...@gmail.com -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP22 doc
The idea to pass the reference of the tool, is just to have a collection of instantiable classes. This allows me to create the toolbar and keymap with their class attributes without instantiating the classes. And leave the __init__ method available for more important things, as window creation and that kind of things. If I don't handle the tool trigger in navigation then I have to check for toggled tools, to untoggle others. And if toggled from keypress then toggle toolbar without calling callback, etc.. Right now this problem doesn't exist because the buttons are not toggle, but I definitively want to use Toggle buttons, I hate that I don't know if zoom is active or not. Why to keep the instances alive? take the example of configuresuplots, in this case if I don't keep the instance alive, I will end with many windows, or having to deal with singletons that I think is not a good idea. Other examples comes to mind, for example if you want to make a logger, you want it to be alive in the background and not being a toggle. Federico On Tue, Jan 28, 2014 at 9:32 PM, Thomas Caswell wrote: > On Tue, Jan 28, 2014 at 7:27 PM, Federico Ariza > wrote: >> activate: I agree with you, renamed to trigger >> >> [I don't understand. The `__init__` gets called when the tool object >> is created (and it gets registered with a particular >> `NavigationBase`/`Figure`/`canvas`. The tool object then sits around >> doing nothing waiting to be triggered. I can see wanting to remove >> one of these buttons, in which case it will need to be un-registered] >> >> I am not expressing myself correctly, what I am trying to say is that >> the Tool object is only created when the tool is triggered. >> The tool.trigger method is called in the ToolBase.__init__ method >> For ToolBase tools, the object is not registered, so there is no >> reference to it anywhere, so it should be garbage collected. I can add >> a del to the object but I think is unnecesary. >> ToolPersistentBase >> [shouldn't `__init__` be called when the tool is created? >> I think the confusion here is that I don't create the tools until they >> are triggered, until then, is just a reference to the class. in the >> navitaion._tools dict. > > If you do not instantiate the object until the button get pushed, why > even bother with a class, can't this just be a function? I still > think it would be better create the `Tool` objects when you create the > figure and then call their `trigger` function when the button gets > pushed. For one thing, this makes it dead-simple to rig up the gui > side of things (at least in Qt, I would assume the others are similar > `button.clicked.connect(self._home_tool.trigger)` ) as the functions > we care about already look like call-backs. I am not sure that the > benefit of doing it the way you wrote it (with the button-push-time > object creation) is worth the added complexity. > > > I think we only need two kinds of tools, the kind you push once and > they fire off an action (simple push button, need one public function > `trigger` this works for simple actions home, quit, back and things > that create extra windows) and the kind you can toggle on and off > (need two public functions `enable` and `disable` which are what they > do when you turn them on (set up call backs to grab input) and turn > them off (tear down/disconnect the canvas call backs) which eliminates > much of the need for keeping track of locks (I think). The toggle > kind may or may not be group in to exclusion groups (pan/zoom) but I > could see doing 'toggle grid lines' as this type as well. > > Tom > > -- > Thomas Caswell > tcasw...@gmail.com -- Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? -- Antonio Alducin -- -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Replacing matplotlib.delaunay natural neighbor interpolation
On Tue, Jan 28, 2014 at 12:59 AM, Ian Thomas wrote: > I expect we will add more triangular grid interpolators to matplotlib in > due course and I am happy to receive suggestions on this. However, this > will not include natural neighbour. Natural neighbour interpolation is > specific to delaunay triangulation, and as we also support user-specified > triangulations I am only interested in interpolation that covers all > triangulations. > I appreciate the separation of the triangulation from the interpolation, but I also like natural neighbor. But is it really only usable with delauney triangulations I can see that it may not have very nice properties when applied with a very non-delaunay triangulation, but I can't see why it it wouldn't be computable. Or am I missing something? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
