This issue is discussed in the documentation:
http://www.mathworks.com/help/techdoc/math/bspqjle-1.html

When you call DELAUNAY with a set of points that contain duplicates you will discover some data points are not referenced by the triangulation. If you were to use that triangulation to develop an algorithm, this could cause problems.

Adding a method to DelaunayTri to provide information about duplicates may seem like a good idea at first. But in terms of interface design we are really concerned about the separation of responsibility. DelaunayTri is for triangulating data and querying that triangulation. Eliminating duplicates is the responsibility of another function. Besides, you would still need to intervene to get what you want. For example, when eliminating duplicates you may wish to average the corresponding Z values.

As far as updating your Z goes, you may also wish to take a look at this section on interpolation:
http://www.mathworks.com/help/techdoc/math/bsou4rj-1.html#bsphz74-1

[DT,ind] = DelaunayTri(X,Y);  %??

where ind is a list of the DT.X output index receiving each XY input point (for use in accumarray)?

This is a good question on a usecase I can see has practical relevance.
When we design a feature like this we try to strike a balance between functional ease-of-use
and complexity associated with the more advanced bells and whistles.

Your usecase falls into the advanced category and while TriScatteredInterp doesn’t readily provide a “canned” solution you can do this with a couple of extra steps.

We will reuse the above example that illustrated boundary slivers and create a DelaunayTri from the data as before.

t= 0.4*pi:0.02:0.6*pi;
x1 = cos(t)';
y1 = sin(t)'-1.02;
x2 = x1;
y2 = y1*(-1);
x3 = linspace(-0.3,0.3,16)';
y3 = zeros(16,1);
x = [x1;x2;x3];
y = [y1;y2;y3];
dt = DelaunayTri(x,y);

We can use the aspect ratio (AR) of the triangle as a rejection criterion; the AR being defined as the ratio of the incircle radius to circumcircle radius.
I did some experimenting and found 0.01 was a good threshold for this example.

[~, Ric] = dt.incenters();
[~, Rcc] = dt.circumcenters();
AR = Ric./Rcc;

Now find the indices of the admissible triangles and visually inspect.

Tadmissible = find(AR > 0.01);
trisurf(dt(Tadmissible  ,:),x,y,zeros(size(x)))

Assign NaNs to the points that are not within our region of interest.
We will use the same query data as before and use the pointLocation method provided by DelaunayTri to find the triangles enclosing the points.

[xi,yi] = meshgrid(-0.3:.02:0.3, -0.0688:0.01:0.0688);
gridsize = size(xi);
xi = xi(:);
yi = yi(:);
% Initialize the corresponding values using NaNs and later replace the valid entries.
zi = NaN(size(xi,1),1);
Tenclosing = dt.pointLocation(xi,yi);
validxiyi = ismember(Tenclosing,Tadmissible );

You can reuse the DelaunayTri by passing it to TriScatteredInterp – don’t waste anything you can reuse!

z = x.^2 + y.^2;
F = TriScatteredInterp(dt,z);
%
% Evaluate the interpolant at the valid query locations
zi(validxiyi) = F(xi(validxiyi), yi(validxiyi))
% Reshape the data so we can call mesh
xi = reshape(xi,gridsize );
yi = reshape(yi,gridsize );
zi = reshape(zi,gridsize );
mesh(xi,yi,zi)
xlabel('Interpolated surface', 'fontweight','b');

If linear interpolation suffices, you could use DelaunayTri to perform the interpolation.
The pointLocation method returns the Barycentric coordinates bc which are used to weight the values at each vertex of the enclosing triangle.

dt = DelaunayTri(x,y);
z = x.^2 + y.^2;
[ti bc] = dt.pointLocation(xi,yi);
T = dt.Triangulation;
zi = z(T(ti,1)).*bc(:,1)+z(T(ti,2)).*bc(:,2)+z(T(ti,3)).*bc(:,3)

The user documentation for Scattered Data Interpolation has been revised recently and may help clarify the latter approach.
http://www.mathworks.com/help/techdoc/math/bsou4rj-1.html

Note thaat this, effectively imposes a non-convex boundary on the interpolation.

In item #21 above, I outlined the approach to handling duplicate data points in the scenario where the interpolant is to be reused with different values V. This suggests removing the duplicates prior to performing the interpolation and the steps to do this are provided.

TriScatteredInterp allows X and V to behave independently of each other. This flexibility allows the underlying triangulation to be reused when V is changed and this is very desirable because a retriangulation of X incurs an overhead. In your duplicate point scenario X and V are not strictly independent of each other and the design cannot handle both situations faithfully.

TriScatteredInterp cannot and should not remember which points were merged when the interpolant was created,
because when the interpolant is subsequently edited we cannot assume intent.

The user may wish to replace V and retain the same locations X, OR the user may wish to replace V and then replace X with a completely different set of locations.
A more conservative design would restrict you to editing both X and V simultaneously; e.g. F.SetData(newX,newV), and this has the same overhead as GRIDDATA.

Thanks for taking the time to provide feedback, we will use it to improve the documentation for this feature.

I’m trying to use TriScatteredInterp, but there’s a catch. The x,y points apparently has some repetition. When I run TriScatteredInterp, I get the following message:

“Warning: Duplicate data points have been detected and removed – corresponding values have been averaged.”

That’s all fine and dandy. (technically though, the message shows up even if there are no values to average – i.e. if I just introduced x,y data by F.X = XY)

But the problem is that I cannot reuse this interpolation F to run over the same x,y points with a different set of z-data, because the other z-data defined over the same x,y will not have the redundant points removed. And that only works if the z-data and x,y are introduced together via the function – F = TriScatteredInterp(X, V). First getting an empty F, then setting F.X = XY, then F.V = data will not work.

If I attempt to use F with other z-data, I get:

“??? Error using ==> subsref
The interpolant is in an invalid state.
The number of data point locations should equal the number of data point values.”

In this case, it looks like I have to create a new interpolant for every set of z-data, which seems highly inefficient, and is only due to a trivial problem of not knowing how to remove the redundant points in the same way.

So I was wondering if you had a solution for this. I could try to manually remove redundant points beforehand, but then I have the added overhead of remembering some indexing matrix for removing redundant points and applying it to any future z-data that may be used, and also averaging the redundant values.

I would suggest that it would be a lot cleaner to internalize this somehow. Since the interpolant is designed to be re-used for different z-data over the same x,y points, it should remember if it had to pre-process the x,y points. Then, any z-data introduced by F.V = data should undergo the same pre-processing, so that the user doesn’t have to worry about nitty gritty details like this.

Maybe I’m just using this wrong and there is an easier way, in which case please let me know!

It is difficult to quantify the performance improvements that can be gained by modularizing your code into functions. It depends on several factors including the functions you are calling, the size of the data, and level of iteration involved, etc. The large performance gains that Mike observed are probably unique to the computational geometry classes in the context of problem size and level of iteration. MATLAB code is designed to execute with optimal performance when structured into functions, so you do not need to be concerned about the internals if you adopt this recommended approach when developing MATLAB applications.

Is such a performance improvement attributable to functions being fully parsed before execution, while scripts are not?

That’s correct, the code must reside in a function to achieve optimal performance.
When MATLAB executes a program that is composed of functions that reside in files, it has a complete picture of the execution of the code; this allows MATLAB to optimize for performance. When you type the code at the prompt MATLAB cannot anticipate what you are going to type next so it cannot perform the same level of optimization. Developing applications through the creation of reusable functions is general and recommended practice, and MATLAB will optimize the performance in this setting.