Re: Suggestion for dgrid3d

[<HBB...@t-...>]

Philipp K. Janert wrote:
> I was just playing with dgrid3d, and had some 
> difficulties getting rather "smooth" input data
> to come out "just right". So I looked into the
> implementation for dgrid3d and wanted to make
> a suggestion.
> 
> Context:
> ======
> dgrid3d evaluates (possibly ungridded) input data
> and calculates a smooth approximation to it on a
> regular grid. The values assigned to each grid point
> are essentially weighted averages:
> 	sum_{all points} w_i * data_i
> The sum runs over all input data points, and the
> weight function w is essentially an inverse power
> of the distance between each data point and the
> current grid point:
> 	w = 1/dist**p      for some integer p

You underestimate the consequences of that little word "essentially" a 
bit.  The actual formula of course is

	sum(w_i * data_i) / sum(w_i)

just as it should be for w_i to deserve being called a "weight".

> Problem:
> ======
> This particular choice of weight function has a few
> disadvantages:
> 1) for dist==0, it is undefined (requiring treatment
> 	as special case)
> 2) for dist > 0 but small, the weight can become
> 	arbitrarily large

As will the sum(w_i), so that levels out.

> 3) for large p, each individual data point totally 
> 	dominates all grid points within dist < 1, but
> 	is irrelevant once dist > 1, with an abrupt
> 	change in behaviour at dist=1 if p gets large.

The normalization by sum(w_i) removes any special role of dist=1.0.

And of course, nobody's being forced to use large p. ;-)

> 4) no way to control the "radius of influence" or
> 	catchment area for data points

There is no such radius, and thus no need to control it.

> I think it would be desirable to have a weight function
> with the following properties:
> 1) bounded

Check, for the actual dgrid3d function, thanks to the sum(w_i) term.

> 2) w( d=0 ) = 1

effectively the case for the actual dgrid3d algorithm (by way of 
special-casing d=0).

> 3) falling smoothly as d -> infty

check.

> 4) have a parameter which smoothly controls the
> 	size of the "catchment radius".

I don't think there should be any such radius at all, in the typical 
case.  The algorithm should be independent of the x and y range of its 
input, if at all possible.

Are you aware of, or have you even tried the alternative dgrid3d 
algorithm, thin plate splines?