Re: Suggestion for dgrid3d

[Philipp K. J. <ja...@ie...>]

> > 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".

Absolutely. And if you had bothered to look
at the attached code, you would have seen
that this is exactly what is being done. I am
not proposing a change here.

But why a weight function w_i that is 
1) discontinuous
2) grows above all bounds?

If nothing else, numerically this is not 
good (round-off). But it also does not
seem to be right that if a grid point
coincides exactly with a data point, it
gets weight 1, and weight 1/eps >> 1 
if the grid point is shifted by a very small
amount eps << 1 from the grid point.


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

Well, I disagree. The documentation says
the current algo is basically a "low pass
filter". So I want a way to control the width
of the pass band of the filter.


>
> 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.

Exactly. But the current one isn't. If x values
are spaced by 100, and y values spaced by 1
in x and y units, the weight function will behave
differently in both directions. The right way to 
do this is to give users (who know their data
and how noisy it is, etc) the opportunity to scale
the distances themselves - thusly achieving
exactly what you propose.