[matplotlib-devel] Delaunay code: future directions?
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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Delaunay interpolator patch: support grid whose width or height is 1
On Mon, Jul 9, 2012 at 4:34 PM, Benjamin Root ben.r...@ou.edu wrote: On Sat, Jul 7, 2012 at 7:30 PM, Amit Aronovitch aronovi...@gmail.comwrote: -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Delaunay interpolator patch: support grid whose width or height is 1
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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Toolbar button for relimiting
On Mon, Sep 27, 2010 at 8:57 PM, Benjamin Root ben.r...@ou.edu wrote: On Mon, Sep 27, 2010 at 1:47 PM, Eric Firing efir...@hawaii.edu wrote: On 09/27/2010 08:35 AM, Benjamin Root wrote: On Mon, Sep 27, 2010 at 1:27 PM, Eric Firing efir...@hawaii.edu mailto:efir...@hawaii.edu 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Proposal for Broken Axes
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 klu...@wisc.edu 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#174; 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
