Re: Suggestion for dgrid3d

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

I still don't think we are really on the same
page about this.

We agree that dgrid3d calculates a weighted
average:
	z = Sum_i w_i(d) z_i / Sum_i w_i(d)
where
	z_i is the i-th raw data point 
	w_i(d) is the weight function

w_i(d) is a function of d, which is the distance
between the i-th raw data point and the current
grid point.

The current implementation uses
	w(d) = 1/d**p 	if d > 0
	w(d) = 1		if d == 0
That means that w(d), as a function of d,
is not continuous at d = 0.

(I am not saying that the resulting approximation
is not smooth as a function of x and y, as you point
out. That is a different question, however.)

The bigger question is whether this matters
all that much.

There are two reasons I don't find the current
implementation optimal.

The lesser reason is this:
For d small, we multiply values by a large coefficient,
form the sum, then divide the large coefficient
out again. Numerically this is not very nice, because
we loose significant digits if we multiply with something,
sum, and then divide it out again. But since dgrid3d
tries to calculate a rough-but-useful approximation,
this is not so big of a problem.

The bigger reason is that I would like to be able to
control the range over which data points contribute
to a grid point average! Ideally, dgrid3d would have
a parameter, which controls the averaging range
smoothly, such that as
	parameter -> 0 dgrid3d yields the raw data
	parameter -> infity dgrid3d averages over all points

I can't really achieve this effect through a power law.
The gaussian that I suggested, however, allows this.
But a Lorentzian (1/(1+(d/a)**2)) would also do.

Did you take a look at the images I posted?
(www.philipp-janert.com/gnuplot) I think the 
Gaussian results in much more natural 
approximations than the current 
implementation does.

Best,

		Ph.




On Monday 22 October 2007 14:44, you wrote:
> Philipp K. Janert wrote:
> > But why a weight function w_i that is
> > 1) discontinuous
>
> It's not really discontinuous.  It's just undefined at d=0, but has a
> continuous continuation (by w=1).  This is really just a coordinate
> singularity.
>
> > 2) grows above all bounds?
>
> Because it doesn't.  The numerator and denominator are unlimited each by
> itself, but the quotient, which is the real weight factor, is limited to
> the interval [0:1], just like it should be.
>
> > 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.
>
> Which is why that's _not_ what we actually do.  The normalization takes
> care of that.  The real weight of a point very close to the sample is
> very close to 1, because its weight will be much larger than all the
> others, so the sum(w_i) will be dominated by it, and those two large
> terms cancel each other.
>
> >> 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.
>
> Not really.  It will _look_ like it behaved differently, because the
> axis ranges are so different.  But that's a plotting artifact, not a
> property of dgrid3d.  The algorithm operates on actual data values
> rather than plot coordinates, and it treats those exactly equally.
>
> If and when that's a problem, data can always be re-scaled before being
> presented to dgrid3d.