Re: [matplotlib-devel] Fixed contouring bugs.
Eric Firing wrote: > Ian, > > I have applied your patch and modified contourf_demo slightly to illustrate > interior masking. Thanks very much for the beautiful work! These contour > bugs that you fixed were major mpl problems--general embarrassments, and > specific impediments to my own applications, since the data sets I work with > often have masked interior regions. (And, I also use line contours on top > of filled contours, so the saddle-point decision fix helps as well.) I'm glad my contribution passes the quality control checks! > It occurs to me that there might be a nice refinement: when following a > masked boundary, how hard would it be to cross the single-cell gap > diagonally instead of proceeding step-wise along the boundary? In the case > of the circular masked region that I added to the contourf_demo, this would > simply smooth out the boundary of that region. > > Eric I think it would be fairly easy to do half a solution to this, but difficult to do it properly. It would be easy to change the edge_walker function to miss out a grid point when, for example, moving clockwise around a masked region from an i-edge to a j-edge. But what should happen in the situations when a contour level intersects one of those two edges: either (a) do nothing, or (b) still do the diagonal cut-off. The do nothing option (a) is easy (!) but means that there will be a mixture of diagonal cut-offs and stepwise changes, which won't look particularly elegant, whereas (b) will mean some pretty serious rewriting as the contouring code will have to deal with these diagonal edges for both contour lines and filled contours, and there will have to be some slightly arbitrary interpolation from the grid z-values to these diagonal edges. So the answer to your question is "difficult but doable". My preference is to leave it as it is, as the current blocky solution is what I expect to see. But I am happy to take a look at it if you/others think it is a good idea. On the subject of contouring masked grids, I sometimes want to specify which grid squares are masked rather than which grid points, i.e. for a grid of nx by ny points I want to specify a mask of (nx-1) by (ny-1) squares. I've discovered that cntr.c uses such a square mask, creating it from the incoming point mask. It would therefore be easy to add support for such a grid by changing the python front end to pass it in. Is this a good idea and would this be useful to others, or am I being overly simplistic? Ian P.S. Eric, I see that you work with Kelvin Richards - he was my PhD supervisor many years ago. Small world! -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] contourf segfaults
Eric, It appears to be caused by an infinite loop, and may well be due to my changes. I'll take a look on Wednesday and get back to you. Ian On 22 February 2010 01:07, Eric Firing wrote: > Ian, > > I hit a bug (segfault) in cntr.c that is likely related to your changes. It > is ID 2956378 in the tracker. Sample script and data file are there. Will > you be able to take a look soon? > > (Not sure whether the following link will work for you.) > https://sourceforge.net/tracker/?func=detail&aid=2956378&group_id=80706&atid=560720 > > Thanks. > > Eric > -- 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] contourf segfaults
Eric,
> I hit a bug (segfault) in cntr.c that is likely related to your changes. It
> is ID 2956378 in the tracker.
Attached is a patch file with a fix for this bug. I've also included
a minimal test file to demonstrate the behaviour before and after the
fix, along with a brief explanation which I can expand upon if you
wish.
Ian
Index: src/cntr.c
===
--- src/cntr.c (revision 8150)
+++ src/cntr.c (working copy)
@@ -605,6 +605,9 @@
}
if (fwd < 0 && level0 && left < 0)
{
+ /* remove J0_START from this boundary edge as boundary is
+ * included by the upwards slit from contour line below. */
+data[edge] &= ~J0_START;
if (n_kind) kcp[n_kind] += kind_start_slit;
return slit_cutter (site, 0, pass2);
}
#!/usr/bin/env python
#
# Minimal example to demonstrate bug ID 2956378 and its fix.
#
# Bug causes infinite loop leading to segmentation fault. Infinite loop occurs
# as contouring code repeated restarts walking around the edge of a masked
# hole that is linked, via a vertical slit, to the contour line below (with a
# lower j-index). Such a hole should not be a contour starting edge as it is
# included in the contour line that it is slit up from. The solution is to
# prevent such a hole from being a possible contour starting edge by removing
# its J0_START flag.
#
# Bug is only visible if there is at least one other starting edge in the same
# row of the grid, otherwise the erroneous starting edge is ignored.
from pylab import *
z = ones((5,6))
z[2,2] = ma.masked
z[:,-2:] = 0
z[1,-1] = 1# Force another contour starting edge in the same row.
levels = [0.5, 2]
contourf(z, levels, alpha=0.5)
colorbar()
contour(z, levels)
axis([-0.2, 5.2, -0.2, 4.2])
show()
--
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
[matplotlib-devel] Contouring unstructured triangular grids
Hello all, I have some code to generate contour plots of unstructured triangular grids that I have volunteered to include in matplotlib. Some discussion of this has occurred in matplotlib-users, see http://sourceforge.net/mailarchive/forum.php?thread_name=hnbpkq%24o03%241%40dough.gmane.org&forum_name=matplotlib-users Before I go ahead, I want to check if others think this would be useful functionality to have in mpl or not. Thanks, Ian Thomas -- 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] Contouring unstructured triangular grids
Ben Axelrod wrote: > I am a little unclear on what this is and what it is used for. It is used to generate contour plots for data that is defined on unstructured triangular grids. Currently mpl supports generating contour plots on regular rectangular grids; if you have an unstructured grid you have to interpolate it onto a regular grid before contouring it. Contouring directly from the triangular grid avoids the need for this interpolation. > Is this to visualize the triangular grid for things like Finite Element > Analysis (FEM) and Computational Fluid Dynamics (CFD)? FEM and CFD are indeed big application areas for unstructured triangular grids. > What kind of format is the data in? At its simplest, assume you have n irregular spaced points defined by x and y positions and you wish to contour some field z defined at those points, where x, y and z are length n numpy arrays or lists. You will use something like tricontour(x, y, z) A default (Delaunay) triangulation will be constructed and contoured for your pleasure. Alternatively, if you want to specify your own triangulation instead you can do that using a indices array of shape (3, ntri) where ntri is the number of triangles, and indices[:, i] defines the indices of the three points that the i-th triangle is composed of. > Are there any standards for this type of thing? I have no idea. I'm not proposing any file converters for/from any standard file formats as all the information required for such a grid is contained in the rather simple x, y and indices arrays. > Do you have some example code or images? My original posting of September last year includes source code, examples and images. See http://sourceforge.net/mailarchive/forum.php?thread_name=4AB3B95B.3090903%40noaa.gov&forum_name=matplotlib-users This was packaged as a separate python module called 'mpl_tri' which you can install and play with as much as you desire. I am now proposing to integrate this into the core of matplotlib as I don't wish to maintain it as a separate project. I've agreed to add a few extras, as discussed in http://sourceforge.net/mailarchive/forum.php?thread_name=hnbpkq%24o03%241%40dough.gmane.org&forum_name=matplotlib-users Before going ahead with this I wished to ascertain how much interest there was for this functionality as I don't want to spend time doing something that isn't wanted or needed. I hope that answers your questions, Ian -- 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] Contouring unstructured triangular grids
Replying to everyone at the same time: (spot the person in the UK!) Chris Barker wrote: > That would be better as (ntri, 3), to be compatible with the usual C > ordering of numpy arrays. Of course. John Hunter wrote: > I am a little concerned about the "hand wrapped python" part > because of the possibilities of introducing memory leaks and > difficulties it may pose in the matplotlib 2->3 transition. > It would probably be beneficial, but by no means required, to use > CXX to expose the C++ part to python so take a look if you are > inclined. I've taken a look at CXX and it looks like a much more pleasant solution, so I'm happy to use that instead. > I'm also a bit concerned by the maintenance aspect, since this > is a fairly sophisticated piece of code. We'd be looking for a > commitment to support it if we include it in mpl. Understood. I'm uneasy about making a major commitment at this stage as I'm new to open source contributions, so how about you ask me again when I've submitted the code and people have had the chance to review/correct/admire/destroy it? > Eric Firing wrote: > One possibility would be to develop the tri* functionality at least > initially as a module in lib/mpl_toolkits, like axes_grid and mplot3d; > or in a module in lib/matplotlib. This could still take advantage of > refactoring in contour.py. An advantage is that it would consolidate > the triangle functionality so it would be easier to find, track, and > document. I like the idea of putting it in its own directory under lib/matplotlib. > What sort of timeline do you have in mind? I am currently "between jobs", which leaves me plenty of spare time for interesting projects. I reckon I should have something worthy of consideration in 2 weeks time. Ian -- 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] Contouring unstructured triangular grids
Eric Firing wrote:
> I've only glanced so far, but one thing that caught my eye is your
> documentation changes and code regarding the need for simply-connected
> paths. This is obsolete--mpl now handles multiply-connected paths.
Thanks for clarifying this, I now understand the 'point kinds' in
cntr.c which I originally thought were for debug purposes. It will
make my code simpler in the end.
> A second initial suggestion is that you divide the work into two patches,
> one of which provides the refactoring of existing code (presumably only in
> contour.py), and a second which adds the new functionality.
Good idea. I've attached the first patch which changes axes.py and
contour.py, plus adds the new example contour_manual.py. My approach
to the refactoring is probably more of a C++ than pythonic way of
thinking with derived classes that override base class methods, but it
avoids changing much of the low level code and avoids code duplication
when tricontour is added in.
Ian
Index: lib/matplotlib/contour.py
===
--- lib/matplotlib/contour.py (revision 8226)
+++ lib/matplotlib/contour.py (working copy)
@@ -577,7 +577,7 @@
class ContourSet(cm.ScalarMappable, ContourLabeler):
"""
-Create and store a set of contour lines or filled regions.
+Store a set of contour lines or filled regions.
User-callable method: clabel
@@ -592,17 +592,49 @@
same as levels for line contours; half-way between
levels for filled contours. See _process_colors method.
"""
-
-
def __init__(self, ax, *args, **kwargs):
"""
Draw contour lines or filled regions, depending on
whether keyword arg 'filled' is False (default) or True.
-The first argument of the initializer must be an axes
-object. The remaining arguments and keyword arguments
-are described in ContourSet.contour_doc.
+The first three arguments must be:
+ *ax*: axes object.
+
+ *levels*: [level0, level1, ..., leveln]
+A list of floating point numbers indicating the contour
+levels.
+
+ *allsegs*: [level0segs, level1segs, ...]
+List of all the polygon segments for all the *levels*.
+For contour lines len(allsegs) == len(levels), and for
+filled contour regions len(allsegs) = len(levels)-1.
+
+level0segs = [polygon0, polygon1, ...]
+
+polygon0 = array_like [[x0,y0], [x1,y1], ...]
+
+ *allkinds*: None or [level0kinds, level1kinds, ...]
+Optional list of all the polygon vertex kinds (code types), as
+described and used in Path. This is used to allow multiply-
+connected paths such as holes within filled polygons.
+If not None, len(allkinds) == len(allsegs).
+
+level0kinds = [polygon0kinds, ...]
+
+polygon0kinds = [vertexcode0, vertexcode1, ...]
+
+If allkinds is not None, usually all polygons for a particular
+contour level are grouped together so that
+
+level0segs = [polygon0] and level0kinds = [polygon0kinds].
+
+Keyword arguments are as described in
+:class:`~matplotlib.contour.QuadContourSet` object.
+
+**Examples:**
+
+.. plot:: mpl_examples/misc/contour_manual.py
"""
self.ax = ax
self.levels = kwargs.get('levels', None)
@@ -638,24 +670,7 @@
raise ValueError('Either colors or cmap must be None')
if self.origin == 'image': self.origin = mpl.rcParams['image.origin']
-if isinstance(args[0], ContourSet):
-C = args[0].Cntr
-if self.levels is None:
-self.levels = args[0].levels
-else:
-x, y, z = self._contour_args(args, kwargs)
-
-x0 = ma.minimum(x)
-x1 = ma.maximum(x)
-y0 = ma.minimum(y)
-y1 = ma.maximum(y)
-self.ax.update_datalim([(x0,y0), (x1,y1)])
-self.ax.autoscale_view()
-_mask = ma.getmask(z)
-if _mask is ma.nomask:
-_mask = None
-C = _cntr.Cntr(x, y, z.filled(), _mask)
-self.Cntr = C
+self._process_args(*args, **kwargs)
self._process_levels()
if self.colors is not None:
@@ -673,28 +688,23 @@
kw['norm'] = norm
cm.ScalarMappable.__init__(self, **kw) # sets self.cmap;
self._process_colors()
+
+self.allsegs, self.allkinds = self._get_allsegs_and_allkinds()
+
if self.filled:
if self.linewidths is not None:
warnings.warn('linewidths is ignored by contourf')
-lowers = self._levels[:-1]
-if self.zmin == lowers[0]:
-# Include minimum values in lowest interval
-lowers = lowers.copy() # so we don't change self._levels
-if
Re: [matplotlib-devel] Contouring unstructured triangular grids
On 15 April, Ian Thomas wrote: > I've attached the patch for the new triangular grid functionality. As nobody has commented on the patch I submitted to add triangular grid functions, I can only assume that nobody has looked at it. This is a final friendly reminder that some people considered that it would be useful and I'd rather not throw away useful work. Ian -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Contouring unstructured triangular grids
On 11 May, Eric Firing wrote: > I am somewhat inclined to simply commit it, or to give you commit > rights, in view not only of the triangular grid work but of the great > work you did in fixing problems with cntr.c. Do you have a sourceforge > login? I've created a sourceforge login with the username ianthomas23, and I'm happy to commit my patch if you are happy for me to do so. I can confirm that I am prepared to maintain my code in mpl, as John Hunter asked me a while ago. Ian -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Contouring unstructured triangular grids
Patch committed as svn revision 8316. Ian -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Triplot function problems
Hello again Alberto, On 4 July Alberto Azevedo wrote: > When I use the triplot function with 100-1000 points it works well. The > problem is that in my work I often use grids with 3-10 > points. With those grids triplot takes a long time to compute (I never > wait for the results, it takes really a long time). > Yes, it does indeed take a long time for large grids. The bottleneck is line 51 in lib/matplotlib/tri/triplot - I use the plot command which creates a separate Line2D object for each edge in the triangulation, and there can be a lot of edges. There is an obvious improvement of replacing this with a single LineCollection object, but it would require some manipulation of the line styles, colours, etc that the plot command does and I don't yet understand it sufficiently. The matlab triplot function takes just a few seconds, with the same > grids). It's bad etiquette to indicate that matlab is faster when addressing people who give up their free time to improve matplotlib, and possibly counter-productive. And when I was using mpl_tri package, I never had this problem > (the triplot function was faster!!!) > Not true, the final line in the now obsolete mpl_tri.triplot was exactly the same plot() command. I'll take a look at improving the performance, but it won't for a few days. Ian -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Triplot function problems
On 4 July 2010 22:52, Alberto Azevedo wrote: > With those grids triplot takes a long time to compute (I never > wait for the results, it takes really a long time). > Alberto, I've checked some triplot performance improvements into svn. Please can you try out the new version and see if it is OK for your needs. On 5 July 2010 17:40, John Hunter wrote: Thanks for the guidance John; I've done exactly as you suggested. Ian -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in mplot3d contourf
On 22 November 2010 19:08, Benjamin Root wrote: > > Confirmed. Ian, would you mind filing a bug report on this at mpl's > tracker? > I've added a bug report: http://sourceforge.net/tracker/?func=detail&aid=3116341&group_id=80706&atid=560720 Thanks Ben, Ian -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Bug in Triangulation causes infinite loop if 4 or more duplicate points are used in tricontour()
On 16 April 2012 23:36, Damon McDougall wrote: > On Monday, 16 April 2012 at 16:34, Kacper Kowalik wrote: > > > On 16 Apr 2012 22:31, "Damon McDougall" wrote: > > > > Hi Kacper, > > > > Just to be clear, is it tri.Triangulation(x, y) that hangs, or is it > plt.tricontour(…)? > > It's plt.tricontour that hangs, tri.Triangulation properly issues warning > about duplicates. > Cheers, > Kacper > > > On Monday, 16 April 2012 at 14:28, Kacper Kowalik wrote: > > >> > >> Hi, > >> I haven't been able to pin point it exactly but following script: > >> > >> import matplotlib.pyplot as plt > >> import matplotlib.tri as tri > >> import numpy as np > >> from numpy.random import uniform, seed > >> > >> seed(0) > >> npts = 200 > >> x = uniform(-2,2,npts) > >> y = uniform(-2,2,npts) > >> z = x*np.exp(-x**2-y**2) > >> > >> y[1:3] = x[0] # 4 or more duplicate points make tricontour hang!!! > >> x[1:3] = y[0] > > You should call z = x*np.exp(-x**2-y**2) _before_ changing the points > you're triangulating. > Having said that, I see the same behaviour even if I change the vertices > before I compute z. > > >> triang = tri.Triangulation(x, y) > >> plt.tricontour(x, y, z, 15, linewidths=0.5, colors='k') > >> > >> plt.show() > >> > >> > >> causes infinite loop in _tri.so. It happens in matplotlib-1.1.0 as well > >> as git HEAD. > >> I understand that my input is not exactly valid, but I'd rather see MPL > >> die than occupy my box for eternity ;) > >> Best regards, > >> Kacper > > I think the reason it's hanging is because you're trying to plot the > contours of a function that is defined on an invalid triangulation (edges > cross at points that are not in the vertex set). I think the best way to > deal with this is to write a helper function to check the triangulation is > valid. If it isn't, either tri.Triangulation(x, y) should fail, or the > plotter should fail. > > Anybody else have any suggestions? > We can definitely do better here. I have created a issue request on github: https://github.com/matplotlib/matplotlib/issues/838 and will investigate further. Ian -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom plot_trisurf triangulations
On 20 September 2012 22:30, Damon McDougall wrote: > I have been playing with custom triangulations in the plot_trisurf > method of the mplot3d toolkit. I thought I would share my sweet > creation: https://www.dropbox.com/s/ccptm6ok7nd3yn5/mobius.png > > Let me know your thoughts. I should probably make a pull request out > of this, but the code is not currently readable by humans. I will tidy > it up first. Make it look purrty. > Yes please! Ideally it would be good if all mplot3d functions supported the same arg and kwarg combinations as their 2d equivalents, for consistency. You may have done this already, but if not you might find the 2d tripcolor code helpful - it calls Triangulation.get_from_args_and_kwargs(*args, **kwargs) to do the initial heavy lifting. Forgive my cheek, but whilst you are looking at this area mplot3d.tricontour and tricontourf need similar improvement... A wider issue, and something I should have mentioned when you first implemented plot_trisurf, is that I don't like the function name. It seems unnecessary to have the plot_ at the front as most of the other plot-related functions manage without it. My unease extends to plot_surface and plot_wireframe as well. I guess we can't just change such names now that they are being used, but eventually I would like to see better naming within mplot3d. Thanks, Ian -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom plot_trisurf triangulations
On 21 September 2012 14:38, Benjamin Root wrote: > On Fri, Sep 21, 2012 at 6:43 AM, Damon McDougall < > [email protected]> wrote: > >> On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas >> wrote: >> > On 20 September 2012 22:30, Damon McDougall >> > wrote: >> > 3. Create a new args_2d tuple exactly equal to *args but with 'z' >> removed. Then rely on the 2d code with: >> Triangulation.get_from_args_and_kwargs(args_2d, **kwargs). Since this >> option would be common to all 3d functions relying on the 2d heavy >> lifting, it could be wrapped up into a convenience function. >> >> In my opinion, option 3. is preferable. Option 3. will also produce >> commits with the highest signal-to-noise ratio. >> >> > I agree with option 3. It fits in nicely with the paradigms of the > existing codebase (my recent contributions excluded...) > I am happy with option 3 too, but I don't think you need to do as much as this. The existing 2d triplot/tripcolor/tricontour call Triangulation.get_from_args_and_kwargs, which removes the various args/kwargs needed for the triangulation and leaves the remainder for the calling function to process. For example lib/matplotlib/tri/tricontour.py lines 86 to 88: tri, args, kwargs = \ Triangulation.get_from_args_and_kwargs(*args, **kwargs) z = np.asarray(args[0]) Can't you just do the same here, or am I missing something? > A wider issue, and something I should have mentioned when you first >> > implemented plot_trisurf, is that I don't like the function name. It >> seems >> > unnecessary to have the plot_ at the front as most of the other >> plot-related >> > functions manage without it. My unease extends to plot_surface and >> > plot_wireframe as well. I guess we can't just change such names now >> that >> > they are being used, but eventually I would like to see better naming >> within >> > mplot3d. >> > >> >> >> Agreed. Not sure how best to solve this. Furthermore, I think it >> should be implemented in a pull request separate to the one migrating >> these 3d methods to custom triangulations. >> >> > I wouldn't be against going down a deprecation path for renaming these > functions, but for what gains? The names have been there since before I > took up this toolkit, and ultimately, these functions aren't typed so often > that brevity would gain one much. Definitely any new functions should not > take up that naming, but I see no real compelling reason to change the > existing names. > The gain is that of more consistent naming of the mplot3d api functions. The argument that we should keep names because they have been around for a long time is not a strong one if the names are poor choices in the first place. But I am not particularly concerned as I think that mplot3d has some bigger problems to solve than this e.g. correct rendering of nested polygons, z-order rendering, so maybe I should keep quiet about such details! Ian -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Interpolation in a triangular mesh (tri.Triangulation)
Hi Geoffroy This will certainly be very useful. I need to spend some time looking at it and seeing how it would best fit within the matplotlib framework, particularly as only a few days ago I committed to writing a triangular grid interpolator for quad grids and it would be sensible to group these interpolators together in some way. I'll get back to you when I've had time to look at it. Thanks for your efforts! Ian On 28 October 2012 20:17, GBillotey wrote: >Hi! > > > I had recently to develop interpolators for a function defined at the nodes > of a user-specified triangular mesh. > (Beside interpolation, it can help producing higher-quality tricontour > plots, using interpolation on a refined mesh and matplotlib tricontour > function.) > > Being a regular user of matplotlib, I would be happy if it can be useful to > others... > The code is hosted here: > https://github.com/GBillotey/trimesh-interpolator.git > > > Please let me know if it this dev. can be useful and if the code needs some > cleaning (I am not a computer scientist, only a mechanical engineer) > > > Cheers, > Geoffroy. > -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Interpolation in a triangular mesh (tri.Triangulation)
Hi Geoffroy, I have had some time to look at your TriLinearInterpolator in some detail (the other two files only briefly). I would indeed like to add something like this to matplotlib - the mesh refinement looks very nice and the interpolators would be useful to many people. As you suspected, the code does need significant changes before we can include it. Some are merely cosmetic, as all code must adhere to PEP8 and the matplotlib coding guidelines, but there are also some functional and performance improvements. For example, your wavefront method for finding the triangle containing a certain point must be able to deal with masked triangulations and indeed triangulations that are discontinuous, for example two islands in a masked-out ocean, which is unusual but must be supported. In terms of performance, there is much explicit looping within numpy arrays that could be improved using other numpy array commands, and would also reduce the length of the source code. There is an argument for some of the performance-critical code to be in C/C++. I think the code used to determine which triangle contains a certain point should be factored out into its own TriFinder class, so that (1) it does not need to be replicated in the two interpolator classes, and (2) different algorithms can be easily swapped if necessary. I have a C++ TriFinder class that I could modify to work within matplotlib, and it is O(log N) so should be faster than your version for typical use cases. I expect that this is probably more work than you anticipated when you asked if the code needed any improvement! I propose the following: if you are happy to give matplotlib your source code as it stands and for us to include it under our BSD-style license, then I will take on the responsibility of getting it into a form that will be accepted by the other developers. I will acknowledge your contribution in both the source code and on the web site, something like "based on code contributed by Geoffroy Billotey". Alternatively, if you would like to use this as an excuse to learn how to contribute to matplotlib more actively but don't want to take on everything, then we could divide up the work so that first I write my C++ log(N) TriFinder class and the linear interpolator that uses it, and then you could modify the cubic interpolator following the format of the linear interpolator and using my guidance as and when you need it. Let me know your preference, Ian P.S. Never apologise for not being a computer scientist! Many of our developers, myself included, are proper scientists or engineers!!! On 29 October 2012 09:37, Ian Thomas wrote: > Hi Geoffroy > > This will certainly be very useful. I need to spend some time looking at > it and seeing how it would best fit within the matplotlib framework, > particularly as only a few days ago I committed to writing a triangular > grid interpolator for quad grids and it would be sensible to group these > interpolators together in some way. > > I'll get back to you when I've had time to look at it. > > Thanks for your efforts! > Ian > > > > On 28 October 2012 20:17, GBillotey wrote: > >>Hi! >> >> >> I had recently to develop interpolators for a function defined at the >> nodes >> of a user-specified triangular mesh. >> (Beside interpolation, it can help producing higher-quality tricontour >> plots, using interpolation on a refined mesh and matplotlib tricontour >> function.) >> >> Being a regular user of matplotlib, I would be happy if it can be useful >> to >> others... >> The code is hosted here: >> https://github.com/GBillotey/trimesh-interpolator.git >> >> >> Please let me know if it this dev. can be useful and if the code needs >> some >> cleaning (I am not a computer scientist, only a mechanical engineer) >> >> >> Cheers, >> Geoffroy. >> > -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Interpolation in a triangular mesh (tri.Triangulation)
On 15 November 2012 21:25, Chris Barker wrote: > On Wed, Nov 14, 2012 at 1:50 AM, Ian Thomas wrote: > > > I think the code used to determine which triangle contains a certain > point > > should be factored out into its own TriFinder class, > > +1 -- this is a generally useful feature. In fact, it would be nice if > a lot of this were in a pacakge that deals with triangular meshes, > apart from MPL altogether (a scikit maybe?) > I hadn't considered any wider interest in it. From a selfish matplotlib point of view, even if it was in say a scikit, we wouldn't want to add an external dependency to the scikit so we would still need a copy of the source code within matplotlib anyway, just to do our interpolation for plotting purposes. The situation would be just like the delaunay code which exists in a scikit but we include it in the mpl source code to avoid the external dependency. Once it is in mpl it is available for other projects to use if they wish, subject to the BSD-style license. There would be a question of who is responsible for maintaining it as I don't particularly want to spread myself thinly on other open source projects when there are a lot of additions to mpl that I would like to do. There would be the danger for the other project of the reverse situation of our delaunay example, where we have code that needs improvement but it is essentially unmaintained, causing problems for users and embarrassment for developers. > I have a C++ TriFinder class > > that I could modify to work within matplotlib, and it is O(log N) so > should > > be faster than your version for typical use cases. > > What algorithm does this use? Is the code open source and/or availabel > for other projects? > > I'm working on a package for working with unstructured grids in > general, and also have a use for "what triangle is this point in" code > for other purposes -- and I havne't found a fast, robust code for this > yet. > It is code I have written recently based on the trapezoidal map algorithm from the book 'Computational Geometry: Algorithms and Applications' by M. de Berg et al. It currently exists only on my main linux box, but it will be open source within mpl for others to use as mentioned above (subject to acceptance by the mpl developers of course). It is an excellent book that I wholeheartedly recommend to anyone with a passing interest in computational geometry. The algorithm itself looks painful initially (as do many of the algorithms in the book) but it reduces to a surprisingly small amount of code. For well-formed triangulations (i.e. no duplicate points, no zero area triangles and no overlapping triangles) the algorithm is 'sufficiently' robust. It is not completely robust in the sense of Shewchuk's robust predicates, but is designed quite cleverly (or luckily) to avoid many of the pitfalls that occur in naive point-in-triangle tests. For example, a naive implementation of a point-in-triangle test for a point on or very near the common edge of two adjacent triangles might return true for both triangles (which is usually fine), or false for both (which is catastrophic). The trapezoidal map avoids these problems by reducing the test to a single point-line test which is therefore guaranteed to return just one of the two triangles. It is possible to think of a situation that causes the algorithm to fail at a triangle which has such a small area that the slopes of two of the sides are within the machine precision of each other, but it is also possible to use the triangle connectivity to check for and resolve this problem. I haven't done so yet and need to consider the tradeoff of effort required vs potential gain. Someone who required guaranteed robustness could use Shewchuk's point-line test with the algorithm. I would not do this with mpl however, as the correctness of the point-line test depends a lot on computer architecture and compiler flags. This would get out of date quickly and would need keen monitoring by someone with knowledge of and interest in the area, plus access to a lot of different computer architectures and OSes. I fail on all of those counts! > >> particularly as only a few days ago I committed to writing a triangular > grid > >> interpolator for quad grids > > what is a triangular interpolator for quad grids? sounds useful, too. That was poor English from me. I meant interpolating from a triangular grid *to* a quad grid, typically to make use of the wide range of quad grid plotting functions like contour, pcolor, etc. Ian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day
Re: [matplotlib-devel] Interpolation in a triangular mesh (tri.Triangulation)
On 16 November 2012 05:14, Damon McDougall wrote: > >> I have a C++ TriFinder class > >> that I could modify to work within matplotlib, and it is O(log N) so > should > >> be faster than your version for typical use cases. > > > > What algorithm does this use? Is the code open source and/or availabel > > for other projects? > > I'm pretty sure there is an O(log n) algorithm in the Numerical > Recipes book. It requires you to construct the triangulation in a > specific way (this allows one to set up a tree data structure of > triangles nicely). There may be others that I am not aware of though. > I think this is the standard method used for point-in-triangulation tests for delaunay triangulations, as the search structure is created as the triangulation is built. We need to support non-delaunay triangulations that are specified by the user, which requires a different approach. Ian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
I vote for using the raw Python/C API. I've written a couple of PyCXX extensions and whilst it is mostly convenient, PyCXX doesn't support the use of numpy arrays so for them you have to use the Python/C API. This means dealing with the reference counting yourself for numpy arrays; extending this to do the reference counting for all python objects is not onerous. Dealing with object lifetimes is bread-and-butter work for C/C++ developers. I have never used Cython, but to me the code looks like an inelegant combination of Python, C/C++ and some Cython-specific stuff. I can see the advantage of this approach for small sections of code, but I have strong reservations about using it for complicated modules that have extensive use of templated code and/or Standard Template Library collections (mpl has examples of both of these). I agree that Cython opens us up to a larger body of contributors, but I don't think that this is necessarily a good thing. I think this really means opens us up to a larger body of Python/Cython contributors, and is a view expressed from the Python side of the fence and has the wrong emphasis. I am primarily a C++ developer is a sea of Python developers, and rather than encourage other Python contributors to dip their toes into C/C++ via Cython I think we should be encouraging C/C++ contributors to do what they do best. We only need a few C/C++ developers if we allow them to use their skills in their preferred way, and they are used to interfacing to legacy APIs and dealing with object lifetimes. OK, cards on the table. If we wanted to switch all of our PyCXX modules to use the raw Python/C API, I would happily take on some of the burden for making the changes and ongoing maintenance of such modules. Particularly if, in return, I get some help with my sometimes substandard Python! If we go down the Cython route I couldn't make this offer; would our many Cython advocates take on the responsibility of changing and maintaining my C++ code in this scenario? Ian Thomas -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
Yes, an excellent summary and neatly bringing us back to the crux of the matter. For completeness I should say that I wouldn't use SWIG. I used it about 5 years ago to wrap some C++ for Python and other languages. Initially it was very useful, but eventually the default mapping between C++ and Python types and the default handling of object lifetimes weren't quite what I wanted and I found myself writing a lot of extra configuration code to coax it back in line. In the end I went back to the Python/C API. Perhaps its aim of targetting many different languages means it isn't suited for our language of interest. It doesn't support Numpy arrays anyway. I would like to be able to recommend Boost.Python, but I have never used it. I have used some Boost modules and found all to be well-designed and actively maintained. However, it currently doesn't support Numpy arrays (although it is an active area of work) and it appears that there are difficulties building it with anything other than the default build tool BJam leading to concerns over portability. Although my preference, in the absence of PyCXX, for wrapping our larger C/C++ modules is to use the Python/C API rather than Cython, I have been persuaded that there is a place for Cython in matplotlib. The ability to improve the performance of small sections of Python code in a simple and localised manner seems very useful, and would be a good starting point for speeding up areas of code that a number of users are frustrated by. Given the number of people who would like to see it used in matplotlib, I think it is inevitable that we eventually will. I hadn't really considered the option of adding Numpy arrays to PyCXX. I've taken a quick look at the existing code and whilst I don't think it is a trivial task it looks well worth investigating - the existing code is well organised and quite well documented. If two or more of us were prepared to make the Numpy additions to PyCXX and provide ongoing maintenance, we would address the deficiencies of the current solution and remove the single-person bottleneck. But I am not sure where this leaves us as I a now advocating use of Cython to some extent and hence we would have two wrapping tools. Should we reject Cython + improved PyCXX on these grounds and revert to Cython + Python/C API? Ian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tripcolor() - sluggish execution
On 17 December 2012 14:04, campbell.kb wrote: > I am an environmental computer modeler. I've created scripts that use > tripcolor() to do contour plots of various output variables (with values at > the centers of triangles and at the corners of the triangles). The grids I > am working on are rather large (I am involved in modeling the United > States' > Great Lakes). The issue is that tripcolor() is exceedingly slow to use > because I am producing contour plots for 3 variables, for all 48 time steps > in a 48 hour forecast. Is there any chance that the tripcolor() function > can > be sped up, or is there anything I should do (in generating the arguments > passed to it) that would speed up its execution time? > There is probably something you can do to speed up your execution time, but for us to help we will need to see exactly what you are doing. Can you post an example of one of your slow scripts with the appropriate data? As you are dealing with large datasets you may want to simplify the example script/data you send. If the data is still too large and/or you don't want to post it to a public mailing list, you can email it to me directly. Ian Thomas -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tripcolor() - sluggish execution
The discussion of this thread was continued off the mailing list as the example script/data were too large to post to the list. Here is a simplified summary so that others who find this thread will benefit too. The original poster had a script like the following: for i in range(48): fig = figure(...) ax = fig.add_subplot() ax.tripcolor(lons, lats, triangles, values, ...) # other plotting of coastlines, text, changing fig/ax settings, etc. fig.savefig(...) close(fig) Three areas of performance improvement were identified: 1) As lons, lats and triangles do not change between tripcolor calls, use a single Triangulation object initialised before the start of the loop. This avoids unnecessarily creating, using once and deleting 48 separate Triangulation objects. triangulation = matplotlib.tri.Triangulation(lons, lats, triangles) for i in range(48): ax.tripcolor(triangulation, values, ...) 2) Use tricontourf instead of tripcolor. It is often significantly faster, and you can control the tradeoff of speed verses output quality by changing the number of contour levels used. 3) Reuse the Figure and Axes within the loop. Create them before the loop and do all plotting that is common to all iterations of the loop. Then in the loop do the single tricontourf call. You must make sure you delete the result of the previous iteration's tricontourf call or they will all stack up with each other as you repeat the loop. This is the new pseudocode incorporating all 3 changes: triangulation = matplotlib.tri.Triangulation(lons, lats, triangles) # One and only Triangulation. fig = figure(...) # One and only Figure. ax = fig.add_subplot() # One and only Axes. # plotting of coastlines, text, changing fig/ax settings, etc. ncollections = len(ax.collections) # Number of collections added to Axes so far. for i in range(48): del ax.collections[ncollections:] # Remove collections added in the last loop iteration. ax.tricontourf(triangulation, values, ...) fig.savefig(...) close(fig) These changes reduced the execution time of the OP's code by about a factor of 10 when using 16 levels for the tricontourf call. Ian Thomas -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Delaunay code: future directions?
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
Re: [matplotlib-devel] Delaunay code: future directions?
On 6 March 2013 19:10, Chris Barker - NOAA Federal wrote: > """ > Qhull does not support triangulation of non-convex surfaces, mesh > generation of non-convex objects, ... or constrained Delaunay > triangulations > """ > these are key to my needs, but are they for MPL? > No, all we need is a drop-in replacement for the existing code, i.e. 2D unconstrained Delaunay. Further functionality is outside our remit of "plotting library". I've also got a colleague with some nice code based on Donald Knuth's > Axioms and Hulls monograph. If someone it interested in adding some > tests and python wrappers, I'll bet he'd be glad to release it with a > suitable license. (C++). We've talked about this before and previously I have been interested. But now I think it is unnecessary to maintain our own code when we have a drop-in replacement that has worked so well for scipy. Ian -- 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?
Amit, On 6 March 2013 20:20, Amit Aronovitch wrote: > 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. > The quick working/not working tests without time measurements would be ample, thanks. I will be writing a set of small tests within the mpl testing framework for specific cases that currently fail, but it will be useful to check on some of the big datasets that you use. Ian -- 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
[matplotlib-devel] Directories for C/C++ extensions
Fellow developers, I am working on a PR to replace the use of matplotlib.delaunay with the Qhull library. Installation will be similar to the existing packages LibAgg and CXX in that if the system already has a sufficiently recent version of Qhull installed then matplotlib will use that, otherwise it will build the required library from the source code shipped with matplotlib. I have a thin C wrapper called qhull_wrap.c (following the coding guidelines) which I'll put in the top-level src directory along with most of the existing C/C++ extensions. But my question is where to put the qhull source code? Current practice has separate top-level directories called agg24 and CXX for the LibAgg and CXX packages respectively, so my initial thought was to follow this and create a new top-level directory called qhull to place the library code in. But I don't like this approach of creating a new top-level directory as (1) I think the top-level should remain as simple and uncluttered as possible, (2) it tends to overemphasize the importance of these third-party libraries as they are some of the first directories users see when unzipping the mpl tarball, and (3) it is not immediately obvious that the code in these directories is from third-party libraries rather than something we ourselves have written. Hence my preference is to create a new top-level directory called something like 'third-party' (or should that be 'third_party'?), and place all the third-party libraries in that; i.e. move the agg24 and CXX directories into third-party, and place the new qhull source code in third-party/qhull. What do others think of this idea? Ian Thomas -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Directories for C/C++ extensions
On 7 October 2013 15:22, Michael Droettboom wrote: > I like this idea. I've seen this called "extern" in other projects, but I > don't have a strong feeling about the name. I think it's good idea for all > of the reasons you mention. > OK, 'extern' seems the best directory name. After I've finished the qhull PR I'll create another one to move the existing directories across. Ian -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Directories for C/C++ extensions
On 18 October 2013 19:18, Chris Barker wrote: > Ian, > > > I am working on a PR to replace the use of matplotlib.delaunay with the > > Qhull library. > > nice! -- ( though I sure wish Qhull did constrained delaunay...) > > > Installation will be similar to the existing packages LibAgg > > and CXX in that if the system already has a sufficiently recent version > of > > Qhull installed then matplotlib will use that, otherwise it will build > the > > required library from the source code shipped with matplotlib. > > Why bother, why not just always build the internal version? > > (for that matter, same with agg) > > Wouldn't it be a lot easier and more robust to be sure that everyone > is running the exact same code? > > What are the odds that folks are using qhull for something else, and > even more to the point, what are the odds that the duplication of this > lib would matter one wit? > > This isn't like LAPACK, where folks have a compellling reason to run a > particular version. > > -- just my thoughts on how to keep things simpler. > Chris, Todd has hit the nail on the head. To expand slightly, with the current situation the onus is on us to ensure that mpl builds OK and passes all of our tests with and without each of the external libraries. Linux distro packagers will choose to set up qhull as a required dependency for their mpl package, and once they have done this can simply delete our directory containing the qhull source code in their mpl source package, and it will build OK without any further changes and we can all be confident that it will work correctly. If we always used our internal version then distro packagers would have to change our setup scripts to build using the external libraries. This would be more time-consuming and error prone leading to less timely mpl distro releases. We need to make their job as easy as possible. Ian -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Directories for C/C++ extensions
On 21 October 2013 18:36, Chris Barker wrote: > > we can all be confident that it will work correctly. > > only if you've tested against the version (maybe patched) of the > external lib they are using... > Of course not. We provide the framework to build mpl and run tests. Distro developers choose how they want to build it and then run our tests. If the tests pass then both they and us are confident that it works correctly. We haven't had to test against anyone else's choice of library version. But I'm not maintaining this code, so have at it in the way that makes > sense to you. > This is nothing to do with what makes sense to me; it is about following the existing policy on C/C++ extensions when adding a new one. Just because I am taking time to answer your questions don't presume I am taking a particular stance. In fact I don't have a preference either way, I am just doing the work that is required in a way that is consistent with existing code. If there is a change of policy I am happy to do it a different way. Ian -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem compiling master
On 22 October 2013 07:53, Todd wrote:
> As of last night, I can no longer compile master. I get the following
> error:
>
> building 'matplotlib.ttconv' extension
> creating build/temp.linux-x86_64-2.7/extern/ttconv
> gcc -pthread -fno-strict-aliasing -fmessage-length=0 -O2 -Wall
> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall
> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g -fPIC
> -DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ttconv_ARRAY_API
> -DPYCXX_ISO_CPP_LIB=1
> -I/usr/lib64/python2.7/site-packages/numpy/core/include
> -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.7 -c
> src/_ttconv.cpp -o build/temp.linux-x86_64-2.7/src/_ttconv.o
> src/_ttconv.cpp:12:27: fatal error: ttconv/pprdrv.h: No such file or
> directory
> compilation terminated.
> error: command 'gcc' failed with exit status 1
>
> This happens even when building from a newly-cloned directory. I am
> building on Linux (openSUSE 12.3). There shouldn't be ttconv/pprdrv.h, it
> has been moved to extern/ttconv/pprdrv.h. I can't figure out why it is
> still looking there.
>
Todd,
This is my fault, I would expect to see a '-Iextern' in the compilation
options. Usually this is obtained from CXX().add_flags(), but obviously
not in your case which implies that your CXX is available via pkg-config.
I think either of the following changes will fix the problem:
1) Either adding the following after line 947 in setupext.py:
ext.include_dirs.append('extern')
2) Or changing line 12 of src/_ttconv.cpp from
#include "ttconv/pprdrv.h"
to
#include "extern/ttconv/pprdrv.h"
I'll need to think about which is the better solution. If you can let me
know which of these fix the problem, I'll have a PR out later today.
Ian
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New contouring algorithm
On 31 January 2014 19:51, Eric Firing wrote: > Would the new code be substantially simpler if the blocky capability were > omitted from it? If so, then it seems like it would makes sense to leave > the blocky form to the old code. > Simpler, yes, but not substantially so. I would prefer to keep both blocky and corner-cutting algorithms together so that there is only one extension to maintain when we eventually remove the old code. One thing to keep in mind is the desire for a cleaner separation between > the generation of the contours and their plotting. Sometimes one actually > wants the polygons themselves; for example, topographic contours can be > used to define boundaries for internal wave flux calculations. A student > here at UH is doing exactly this. > That is certainly desirable, but not part of the work I am doing. I am rewriting the C/C++ code that calculates the contours, but the interface between that and the python contour code remains the same, apart from some trivial changes of course. Ian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New contouring algorithm
On 31 January 2014 22:43, Benjamin Root wrote: > Thanks for bringing this back onto the mailing list. > > I am excited for the prospect of new algorithms for contouring. My company > has actually been using the contourf() function for the past few years to > generate the polygons from gridded data to then make shapefiles from those > polygons. Having an rcParam and a kwarg for controlling which algorithm > gets used for contouring would be good for us when we transition to any new > algorithms. > It is good to hear that it will be useful. > I also advocate strongly for better separation between the plotting and > the contouring. I made an attempt awhile back for my work to not have to > call contourf() so that my shapefile library code wouldn't interfere with > anybody's plotting that they happen to be doing, but I just couldn't get a > clean separation. I ended up having to wrap my contouring code as a > sub-process. > This is not in the scope of the work I am doing - see my previous answer to Eric. > Do keep me in the loop about this, as I have a fairly substantial data > source for testing. > Excellent, testing by others will be much appreciated. I won't submit a PR on this until after the impending release so there is plenty of time for testing before the release after that. Ian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] subtle change in trisurf image results
On 25 June 2014 17:55, Benjamin Root wrote: > The mplot3d tests are not run automatically, so I have no idea when this > change happened. But I would suspect it is related to the changes in > triangulation rather than with mplot3d itself. I have zero expertise to say > if one result is more correct than the other. See attached. > > I should note that this particular difference was within the default > tolerance. It was the rendering to PDF that seemed to have enough > difference to trigger a failure. > Ben, You are right, this change occurred when the underlying triangulation code was switched to using qhull. Both before and after pictures are equally correct. A rectangle in the x-y plane is split into two triangles by adding a diagonal. The shortest of the two diagonals should added, so for the analytical solution either diagonal is equally valid. In practice the choice of diagonal depends on the order of operations in the underlying algorithm and how these interact with finite machine precision. Rather than just changing the test image, a better solution would be to modify the relevant example/test code to avoid such degenerate cases that can give problems in the future. The source code for trisurf3d_demo ( http://matplotlib.org/examples/mplot3d/trisurf3d_demo.html) is clearly derived from tripcolor_demo ( http://matplotlib.org/examples/pylab_examples/tripcolor_demo.html), but omits the key line near the beginning of angles[:,1::2] += math.pi/n_angles Putting this line back in will avoid similar problems in the future, and improve the images too. Ian -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] whats_new and api_changes
Fellow developers, I know we are now encouraged when writing a PR not to alter doc/users/whats_new.rst and doc/api/api_changes.rst directly, but rather to create files in the doc/users/whats_new and doc/api/api_changes directories instead. When building the master branch docs I was expecting the contents of these new files to be automagically incorporated in the appropriate doc sections, but this does not happen on my development system (ubuntu 14.04, python 2.7, sphinx 1.2.2). I figure either I am doing something wrong, or this is a bug, or there is manual process at release time to cut and paste the new files into the parent files. Which is it? Ian -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] whats_new and api_changes
On 27 November 2014 at 16:16, Thomas Caswell wrote: > There should be an automatic process, but no one has written it yet. I > think IPython has code we can adapt in their doc build process. I had > planned to deal with this when we cut the next minor/major release. > > Tom > Thanks for letting me know Tom. Ian -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
