Re: [matplotlib-devel] Proposal for Broken Axes

2010-04-16 Thread Amit Aronovitch 
First of all, thanks, klukas for the useful piece of code.

Jae-Joon Lee wrote:
> On Mon, Mar 29, 2010 at 12:30 PM, Jeff Klukas  wrote:
>> # Create BrokenAxes with bottom from 0 to 5 and top from 30 to 35
>> ax = plt.broken_axes(ybounds=[0.,5.,30.,35.])
>> # Plot a line onto BOTH subaxes
>> ax.plot(range(35),range(35))
>>
>> The call to plot would get routed through __getattribute__, which
>> would then call plot for each of the subaxes.  This would be much more
>> intuitive than my existing breaky solution, where you have to loop
>> over all subaxes and plot on each individually.
>>
> 
> How do you want to handle
> 
> l1, = ax.plot(range(35), range(35))
> l1.set_color("r")
> 
> then?
> 

Well, I guess BrokenAxes.plot should return a list of lines instead of a
line in ll.
i.e. something like "[[x.lines[-1] for x in ax.subaxes]]"
would replace "[ax.lines[-1]]" as the return value.
Better yet, instead of a list we should have a "vector-type" proxy
container that should transfer method calls to the contained items.

> I think keeping two (or more) separate artists for each axes while an
> user think there is only one artist (because only one axes is exposed
> to the user) is not a good idea.

Ideally this should really be one artist.
However from JDH's response I understand this would be harder to
implement (using custom transforms or something). Maybe emulating one
using the current implementation (as I suggested above) is good enough.

Meanwhile, this redundant looping for each plot call is annoying, so I
can offer the following compromise: store the subaxes in the parent
(broken)Axes (add "self._subaxes = subaxes" before returning from breakx
and breaky), then add a new plot_subs method:

def plot_subs(self,*args,**keys):
for sub in self._subaxes:
res = sub.plot(*args,**keys)
return res

This is a simplified version, returning just the lines of the last
subaxes, but at least this way you can avoid the looping.


 Regards,
 Amit A.


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Toolbar button for relimiting

2010-09-27 Thread Amit Aronovitch 
On Mon, Sep 27, 2010 at 8:57 PM, Benjamin Root  wrote:

> On Mon, Sep 27, 2010 at 1:47 PM, Eric Firing  wrote:
>
>> On 09/27/2010 08:35 AM, Benjamin Root wrote:
>> > On Mon, Sep 27, 2010 at 1:27 PM, Eric Firing > > > wrote:
>> >
>> > On 09/27/2010 03:46 AM, Dieter Weber wrote:
>> >  > Hi,
>> >  > I'm using matplotlib embedded in my wxpython application and
>> > needed to
>> >  > give users a quick way to relimit a figure, for example after
>> > removing a
>> >  > line from a plot. Therefore I added a button to the toolbar. Do
>> you
>> >  > think it would make sense to include this in matplotlib by
>> default?
>> >
>> > I don't think it would.  The standard toolbar is for typical
>> interactive
>> > use, where I don't think the relimit functionality is needed often
>> > enough to justify having its own button--if at all. Better to keep
>> that
>> > toolbar simple.
>> >
>> > Eric
>> >
>> >
>> > Just playing devil's advocate here...
>> >
>> > Considering how we can now have multiple show() calls and with the
>> > upcoming ipython looking more and more spiffy, could there be a future
>> > use case for this toolbar button?
>> >
>> > On the other hand, how would the inclusion of this button impact users
>> > of other interactive scripts that have added their own buttons?  I mean,
>> > planning for the future, can it be definitively said that matplotlib
>> > will never add anymore toolbar buttons?  Could developers rely on that
>> > real estate not being taken over by rule of "eminent domain", if you
>> will?
>> >
>> > Ben Root
>> >
>>
>> Ben,
>>
>> I don't understand either of your questions.  What's the point?
>>
>> Eric
>>
>>
> First, I am asking if there are no use-cases for this button in the future
> with the advent of an improved ipython environment?  In other words, more
> people may use matplotlib+ipython like a regular MATLAB environment.  Could
> this button be a useful feature later?
>
> Second, irregardless of whether this button is included or not, there have
> been app developers who have added buttons to the toolbar for their own
> use.  Can these developers count on that real estate to always be free?  Can
> we definitively say that matplotlib will never have more buttons added to
> its default toolbar?
>
> Does that make more sense?
>
>
A feature-set that MATLAB has and is missing from matplotlib is editing the
plot via the GUI. You can actually remove lines from the plot without typing
anything in the interpreter. I think it is via a line properties menu, but
maybe you can also get there by right-clicking the line and choosing delete
(can't recall, I'll have to check).
If/when we add support for such things in mpl, the relimit button would
become much more useful.

Until we have that, I think JDH's idea for cross-GUI configurable toolbars
is a better target to aim for.

  AA
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Delaunay interpolator patch: support grid whose width or height is 1

2012-07-07 Thread Amit Aronovitch 
The current implementation of Delaunay interpolator returns NaN for grids
whose x or y has dimension 1 (i.e. when you try to interpolate along a
horizontal/vertical line, or in a single point). See example below.

By looking at the code, it seems that this can be fixed by simple
rearrangement of calculations.
Suggested patch provided here:
https://github.com/AmitAronovitch/matplotlib/commit/f312d864da9c72681eb3db3b5920ae64793c713e(let
me know if you want a pull request).
The suggested implementation is almost identical. It might actually perform
faster in some cases (there is one less multiplication op in the inner
loop). There might be some differences in accuracy, but I believe they
should only become observable in cases where the grid size is very large
(which would probably cause memory problems anyway).

Example (before suggested patch):

>>> from matplotlib.delaunay import Triangulation
>>> tri = Triangulation([0,10,10,0],[0,0,10,10])
>>> lin = tri.linear_interpolator([1,10,5,2.0])
>>> # 2x2 grid works fine
>>> lin[3:6:2j,1:4:2j]
array([[ 1.6,  3.1],
   [ 1.9,  2.8]])
>>> # but not when 1x2, 2x1, 1x1:
>>> lin[3:6:2j,1:1:1j]
array([[ nan],
   [ nan]])
>>> lin[3:3:1j,1:1:1j]
array([[ nan]])
>>>

After suggested patch:

>>> from matplotlib.delaunay import Triangulation
>>> tri = Triangulation([0,10,10,0],[0,0,10,10])
>>> lin = tri.linear_interpolator([1,10,5,2.0])
>>> # 2x2 grid: same same
>>> lin[3:6:2j,1:4:2j]
array([[ 1.6,  3.1],
   [ 1.9,  2.8]])
>>> # but these work now
>>> lin[3:6:2j,1:1:1j]
array([[ 1.6],
   [ 1.9]])
>>> lin[3:3:1j,1:1:1j]
array([[ 1.6]])
>>>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Delaunay interpolator patch: support grid whose width or height is 1

2012-07-10 Thread Amit Aronovitch 
On Mon, Jul 9, 2012 at 4:34 PM, Benjamin Root  wrote:

>
>
> On Sat, Jul 7, 2012 at 7:30 PM, Amit Aronovitch wrote:
>
>>
>>
<-- snipped (sent as issue #997) -->


>>
> I am always a fan of people who test and design their methods against edge
> cases like these, so my hat is off to you.
>


FTR: this was not a case of testing, but of hacking:
I had some code using scipy's delaunay interpolator, and I had to provide
fallback functionality for a machine that does not have a recent scipy
installed (luckily, it had matplotlib :-) ).
Since the sample set was irregular (not a grid) - the easiest (though
inefficient) fix was to loop over the set and use 1x1 grids. At this point
I hit this issue...


> I would suggest putting together a pull request so that we can properly
> test the potential impact such a change could have.
>
>
Done.
   thanks,

   Amit
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Delaunay code: future directions?

2013-03-05 Thread Amit Aronovitch 
Dear MPL-devs,

Currently, matplotlib does Delaunay triangulation using a special 
purpose module written in C++ (if I'm not mistaken, it was originally 
forked off from some SciKit and wrapped into a Python module).
Some people (here and on github issues) had suggested it might need some 
rewrites/modification.
In particular I was wondering if we should continue maintaining it here 
or maybe switch to using some external library.

Since triangulation is not a plotting-specific problem, and some free 
libraries are available for solving it, we might actually benefit in 
terms of efficiency and robustness.

Specifically, I had suggested QHull, which is used by scipy (note that 
now there is also a stand-alone python interface: 
https://pypi.python.org/pypi/pyhull - I did not check that out yet).
@dmcdougall had suggested Jonathan Shewchuk's triangle library (we 
should check the license though - I think it is "for non-commercial 
use", unlike mpl). There are also other alternatives.

On the other hand, there's the issue of minimizing external 
dependencies. I think @ianthomas23 had once mentioned that he is happy 
with having Delaunay code reside in mpl (and, of course, "maintainable" 
is whatever is most convenient for the maintainers).

I apologize for suggesting more tasks without contributing time to work 
on them. Just thought that since I finally sat down to report issue 
#1809 (which seems to be a particularly slippery bug in the code 
mentioned above), it might be a good time to discuss this topic again.

thanks,

 Amit Aronovitch


--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Delaunay code: future directions?

2013-03-06 Thread Amit Aronovitch 
Thanks Ian.

These examples occured when I processed large propriatary datasets. So far,
scipy's triangulation worked whenever matplotlib failed.

When we have a new implementation, it should be quite simple to check if it
works where it had previously failed.
Certainly easier than slicing the data to small chunks and trying to
distill a failing example of reasonable size as I did in this case.

So, "working"/"not working" test (possibly including some time
measurements) I can do on a fairly short notice.
Producing some more examples that fail with the current code might require
several hours of work, so would probably get delayed for a few weeks.

Amit

On Wed, Mar 6, 2013 at 10:53 AM, Ian Thomas  wrote:

> Hi Amit,
>
> I am with you 100% of the way.  We should use an existing open source
> Delaunay triangulator, and my preference is for QHull as well.
>
> "Improved Delaunay triangulator" is on my matplotlib todo list, albeit it
> quite a long way from the top.  I don't tend to use the existing code as I
> usually specify my own triangulations, so I have never seen anything quite
> as embarrassing as issue #1809.  Perhaps I need to bump it up my priority
> list.
>
> If I come up with a possible solution as a PR, would you be prepared to
> help test it?  You seem to have quite a few examples that don't work under
> the existing code and would be very useful for demonstrating if the
> improved code is indeed an improvement.
>
> Ian
>
>
> On 5 March 2013 23:08, Amit Aronovitch  wrote:
>
>> Dear MPL-devs,
>>
>> Currently, matplotlib does Delaunay triangulation using a special
>> purpose module written in C++ (if I'm not mistaken, it was originally
>> forked off from some SciKit and wrapped into a Python module).
>> Some people (here and on github issues) had suggested it might need some
>> rewrites/modification.
>> In particular I was wondering if we should continue maintaining it here
>> or maybe switch to using some external library.
>>
>> Since triangulation is not a plotting-specific problem, and some free
>> libraries are available for solving it, we might actually benefit in
>> terms of efficiency and robustness.
>>
>> Specifically, I had suggested QHull, which is used by scipy (note that
>> now there is also a stand-alone python interface:
>> https://pypi.python.org/pypi/pyhull - I did not check that out yet).
>> @dmcdougall had suggested Jonathan Shewchuk's triangle library (we
>> should check the license though - I think it is "for non-commercial
>> use", unlike mpl). There are also other alternatives.
>>
>> On the other hand, there's the issue of minimizing external
>> dependencies. I think @ianthomas23 had once mentioned that he is happy
>> with having Delaunay code reside in mpl (and, of course, "maintainable"
>> is whatever is most convenient for the maintainers).
>>
>> I apologize for suggesting more tasks without contributing time to work
>> on them. Just thought that since I finally sat down to report issue
>> #1809 (which seems to be a particularly slippery bug in the code
>> mentioned above), it might be a good time to discuss this topic again.
>>
>> thanks,
>>
>>  Amit Aronovitch
>>
>
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel