From: Ian T. <ian...@gm...> - 2012-10-17 07:44:02
|
On 16 October 2012 18:44, T J <tj...@gm...> wrote: > > This is a set of 152 points on a triangle. delaunay is mentioned to > have problems for some pathological cases. Is a complete triangular > grid considered as such a case? > Yes, under certain circumstances! delaunay is not 'geometrically robust', meaning it doesn't take into account machine precision errors when deciding if a point is on one side of a line or not or inside a circle or not, which can result in errors leading to the algorithm failing. It sounds like this should be an easy problem to solve but it isn't. In your example the y-values that presumably should be in a straight line about y=-0.5 feature variations at about the 16th decimal place that are causing the algorithm to fail. If these variations were much larger or much smaller, the algorithm would probably work. The first time the failure occurs is at the 20th point, which you can see if you add a call to something like plt.tripcolor(x, y, np.zeros_like(x), alpha=0.5) The darker blue colour shows two triangles overlapping, which shouldn't happen. You have a number of options: 1) Round your x and y values to a smaller number of decimal places, e.g. x = x.round(8) y = y.round(8) On my machine 8 decimal places is good, 10 isn't. 2) Add extra noise to your point positions, which is the classic way to get around this delaunay limitation, e.g. x = x + 1e-6*np.random.rand(len(x)) y = y + 1e-6*np.random.rand(len(x)) 3) Specify the triangulation yourself, which is usually pretty easy for regular cases like yours. See tricontour_demo.py for an example of how to specify a triangulation in your tri* function calls. I hope this helps, Ian |