gnuplot-beta

Suggestion for dgrid3d

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

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

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
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.
4) no way to control the "radius of influence" or
	catchment area for data points

Suggestion:
========
I think it would be desirable to have a weight function
with the following properties:
1) bounded
2) w( d=0 ) = 1
3) falling smoothly as d -> infty
4) have a parameter which smoothly controls the
	size of the "catchment radius".

A Gaussian is the first thing that comes to mind.

I have tried it and quite like the results. I have 
posted some example images comparing Gaussian
weighting vs the power law weighting at:
	www.philipp-janert.com/gnuplot

Optional:
======
I have hijacked the "norm" parameter to 
control the width of the Gaussian. This is
not ideal - a better solution would be to
extend the dgrid3d option in such a way
that it can take two float values (instead
of an int), which can be used to scale the
x- and y-distances independently.

Attached, you will find a patch file (against 
CVS head) containing the changes to use
a Gaussian instead of a power law. They
do not include the "optional" feature 
mentioned above. 

Please let me know what you think. I have 
not prepared a patch to the documentation
yet - I'd like to hear opinions on this 
suggestion first.

Best,

		Ph.

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?

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.

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.

Re: Suggestion for dgrid3d

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

Hans-Bernhard:

I see. This explains our miscommunication: we
use different terminology. I call w(d) the weight
function (which is entirely independent of the
data set), whereas you use this term for the
fully normalized coefficient:
	w(d_i) / Sum_i w(d_i)

Ok.

Now, the real question is, what are the relative
advantages for different choices of w(d)? What
I am missing most strongly in the current 
implementation is a way to control the radius 
over which data points are averaged to form 
the smooth approximation - control over the
"band width" of the low pass filter. 

With the suggestion I made, this can be done -
without forcing the user to pre-process the 
data outside of gnuplot. It seems this would
be a useful feature.

Best,

		Ph.



On Tuesday 23 October 2007 12:19, you wrote:
> Philipp K. Janert wrote:
> > 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
>
> Let's make that w(d_i).  It's the distance d that depends on i, not the
> function that turns a distance into a w.
>
> We at least partly disagree at this point.  The actual weight function
> is not w(d_i), but
>
> 	W_i := w(d_i) / Sum_j w(d_j)
>
> This is smooth (continuous even at d_i = 0), and it's limited to [0:1]
> as weights should be.
>
> > The current implementation uses
> > 	w(d) = 1/d**p 	if d > 0
> > 	w(d) = 1		if d == 0
>
> No, it doesn't.  It's not really w(d), but the final W_i that's set to
> 1.  This is achieved indirectly, by breaking out of the summation loop,
> such that the result becomes the first input point with d==0.
>
> > 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.
>
> Multiplication doesn't lose digits at all, and summation only does where
> it has to, irrespective of scale.  The multiply/divide pair has
> effectively no effect on numerical accuracy at all.  In other words, the
> given algorithm is quite unlikely to have any bigger problem with
> round-off than a gaussian filter kernel would.

Re: Suggestion for dgrid3d

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

Philipp K. Janert wrote:
> 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

Let's make that w(d_i).  It's the distance d that depends on i, not the 
function that turns a distance into a w.

We at least partly disagree at this point.  The actual weight function 
is not w(d_i), but

	W_i := w(d_i) / Sum_j w(d_j)

This is smooth (continuous even at d_i = 0), and it's limited to [0:1] 
as weights should be.

> The current implementation uses
> 	w(d) = 1/d**p 	if d > 0
> 	w(d) = 1		if d == 0

No, it doesn't.  It's not really w(d), but the final W_i that's set to 
1.  This is achieved indirectly, by breaking out of the summation loop, 
such that the result becomes the first input point with d==0.

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

Multiplication doesn't lose digits at all, and summation only does where 
it has to, irrespective of scale.  The multiply/divide pair has 
effectively no effect on numerical accuracy at all.  In other words, the 
given algorithm is quite unlikely to have any bigger problem with 
round-off than a gaussian filter kernel would.

Re: Suggestion for dgrid3d

[<pl...@pi...>]

On Tue, 23 Oct 2007 17:09:10 +0200, Philipp K. Janert <ja...@ie...>  
wrote:

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

As you said the gaussian would be an obvious choice , having a finite  
weight close to zero seems essencial.

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

Nice plots , I think you illustrate the point very well . There are some  
obvious artifacts in the current model particularly heavy in the lower  
order plots.

I think your suggestion is a marked improvement from a theoretical point  
of view and that your example points out that the magnitude of the  
improvements possible by applying a more suitable weighting function.

Nice contribution. I hope it gets adopted.

/Peter.

Re: Suggestion for dgrid3d

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

snip

>
> As you said the gaussian would be an obvious choice , having a finite
> weight close to zero seems essencial.
>

snip

>
> Nice plots , I think you illustrate the point very well . There are some
> obvious artifacts in the current model particularly heavy in the lower
> order plots.
>
> I think your suggestion is a marked improvement from a theoretical point
> of view and that your example points out that the magnitude of the
> improvements possible by applying a more suitable weighting function.
>
> Nice contribution. I hope it gets adopted.

Thanks. 

The next step up would be to have two-different
scale factors as part of dgrid3d - one for the 
x- and y-directions, respectively. Then the weight
function becomes:
	exp( - (x/x0)**2 + (y/y0)**2 )
which means that you can now control the radius
of influence for both x and y IN THE UNITS OF THE
DATA ITSELF, without having to resort to rescaling
your data outside of gnuplot.

I think this would be really useful.

Best,

		Ph.

Re: Suggestion for dgrid3d

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

Philipp K. Janert wrote:

> Now, the real question is, what are the relative
> advantages for different choices of w(d)?

Well, the primary advantage of the current choice is that it _is_ the 
current choice.  dgrid3d must have been in gnuplot for over a decade 
now.  Changing it now would require careful consideration to ensure 
backward compatibility.

> What
> I am missing most strongly in the current 
> implementation is a way to control the radius 
> over which data points are averaged to form 
> the smooth approximation - control over the
> "band width" of the low pass filter. 

Well, as I said before, there is no such radius, thus nothing to be 
controlled.  OTOH, that's how the algorithm manages to work without 
knowing anything about the data.  I.e. the algorithm is invariant under 
some rescaling of the input.  The surface generated by dgrid3d for

	splot 'data' using ($1*s_xy):($2*s_xy):($3*s_z)

looks the same for any s_xy and s_z (setting aside different choices by 
the autoscaling algorithm).  Only if you scale x and y differently, the 
result changes.  One aspect where this helps is that you don't have to 
adjust the settings for every plot.

Maybe it's the wording in the documentation that's misleading here. 
dgrid3d is a kind of low pass filter, but it's a rather different kind 
than you're used to.  It's sort of an auto-adjusting low-pass filter. 
It has no predefined limiting frequency.

Re: Suggestion for dgrid3d

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

On Wednesday 24 October 2007 12:10, you wrote:
> Philipp K. Janert wrote:
> > Now, the real question is, what are the relative
> > advantages for different choices of w(d)?
>
> Well, the primary advantage of the current choice is that it _is_ the
> current choice.  dgrid3d must have been in gnuplot for over a decade
> now.  Changing it now would require careful consideration to ensure
> backward compatibility.

That's a good point. What kind of things do 
are you thinking of that depend on the current 
implementation? Changing the weight function 
does not seem to break any existing code, as
far as I can see.

The best way forward might be to put the
choice into the hands of the USER anyway.
We can add an option to dgrid3d which selects
the filter, defaulting to the current one (this
would guarantee that the behaviour of existing
gnuplot scripts does not change.

>
> > What
> > I am missing most strongly in the current
> > implementation is a way to control the radius
> > over which data points are averaged to form
> > the smooth approximation - control over the
> > "band width" of the low pass filter.
>
> Well, as I said before, there is no such radius, thus nothing to be
> controlled.  OTOH, that's how the algorithm manages to work without
> knowing anything about the data. 

Yes, that's true. But I think that's exactly what 
would be nice to have - to put the ability to 
control the range into the hands of users, who
DO know their data! For example, if I know that
my data is very smooth, but not on a grid, I might
want to use dgrid3d with a small averaging range,
just to get a surface drawn. But when I know my data 
to be noisy, I might want to have a wide averaging
range, to get some of the noise out. The point
is that putting control into the hands of the user
allows the user to get more value out of the tool.
(We can still provide the current behaviour as
default, so there is no change unless requested.)

> I.e. the algorithm is invariant under 
> some rescaling of the input.  The surface generated by dgrid3d for
>
> 	splot 'data' using ($1*s_xy):($2*s_xy):($3*s_z)
>
> looks the same for any s_xy and s_z (setting aside different choices by
> the autoscaling algorithm).  Only if you scale x and y differently, the
> result changes.  One aspect where this helps is that you don't have to
> adjust the settings for every plot.
>
> Maybe it's the wording in the documentation that's misleading here.
> dgrid3d is a kind of low pass filter, but it's a rather different kind
> than you're used to.  It's sort of an auto-adjusting low-pass filter.
> It has no predefined limiting frequency.

Re: Suggestion for dgrid3d

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

Philipp K. Janert wrote:
> On Wednesday 24 October 2007 12:10, you wrote:
>> Philipp K. Janert wrote:
>>> Now, the real question is, what are the relative
>>> advantages for different choices of w(d)?
>> Well, the primary advantage of the current choice is that it _is_ the
>> current choice.  dgrid3d must have been in gnuplot for over a decade
>> now.  Changing it now would require careful consideration to ensure
>> backward compatibility.
> 
> That's a good point. What kind of things do 
> are you thinking of that depend on the current 
> implementation? 

That's exactly the problem with long-standing de-facto standards --- 
there's no way of knowing if and how people's usage have come to depend 
on it.

We do consider backward compatibility a bit of a holy grail in this 
project.  It's always bad if a change to the program modifies the result 
of a previously established usage.  So new features (like a modified 
weight function) should always be introduced such that they're only 
triggered by commands that would have done nothing useful in earlier 
versions.

> Changing the weight function does not seem to break any existing
> code, as far as I can see.

It's not the code, but it's usage we should be worried about here.

>> Well, as I said before, there is no such radius, thus nothing to be
>> controlled.  OTOH, that's how the algorithm manages to work without
>> knowing anything about the data. 

> Yes, that's true. But I think that's exactly what 
> would be nice to have - to put the ability to 
> control the range into the hands of users, who
> DO know their data! 

I'm afraid you're still thing "filter radius" when you now say "range".
When I say range, I mean the xrange and friends.  That's sufficiently 
controllable by the user.

> For example, if I know that
> my data is very smooth, but not on a grid, I might
> want to use dgrid3d with a small averaging range,
> just to get a surface drawn. But when I know my data 
> to be noisy, I might want to have a wide averaging
> range, to get some of the noise out.

This kind of "range" control is what the power parameter is about.
The higher the power, the more local the filter.  But it's not a range: 
its effect changes with the distribution of input points.

Re: Suggestion for dgrid3d

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

(snip)
>
> We do consider backward compatibility a bit of a holy grail in this
> project.  It's always bad if a change to the program modifies the result
> of a previously established usage.  So new features (like a modified
> weight function) should always be introduced such that they're only
> triggered by commands that would have done nothing useful in earlier
> versions.

That's fine - this is the reason why I suggested adding
an additional (optional) argument to dgrid3d, which 
allows the user to select the smoothing kernel. It would
default to the current kernel (thus not breaking any
existing apps), but allows users to make a different
choice for new development.

(snip)
> >
> > Yes, that's true. But I think that's exactly what
> > would be nice to have - to put the ability to
> > control the range into the hands of users, who
> > DO know their data!
>
> I'm afraid you're still thing "filter radius" when you now say "range".
> When I say range, I mean the xrange and friends.  That's sufficiently
> controllable by the user.

It seems as if we still have terminology problems.
Yes, I mean "filter radius" - I am obviously not 
talking about the plot range here!

>
> > For example, if I know that
> > my data is very smooth, but not on a grid, I might
> > want to use dgrid3d with a small averaging range,
> > just to get a surface drawn. But when I know my data
> > to be noisy, I might want to have a wide averaging
> > range, to get some of the noise out.
>
> This kind of "range" control is what the power parameter is about.
> The higher the power, the more local the filter.  But it's not a range:
> its effect changes with the distribution of input points.

But the effect is just not very good. Did you ever
check out the samples I show at
	www.philipp-janert.com/gnuplot

There, I show a very "smooth" data set. Using 
dgrid3d on it introduces all kinds of spurious
"wiggles" and NO choice of the power parameter
gets rid of them.

The gaussian kernel on the other hand leads to
quite faithful representation of the data set.

Please: let's get past the discussion of the 
status-quo and instead start to look forward.
I have tried to give several reasons why having
a gaussian kernel can be desirable. If we add
an optional argument, so that users decide
which kernel to use, we don't break any existing
apps. And we provide more value for the users. 
What's wrong with that?

Best,

		Ph.

Re: Suggestion for dgrid3d

[Petr M. <mi...@ph...>]

> > We do consider backward compatibility a bit of a holy grail in this
> > project.  It's always bad if a change to the program modifies the result
> > of a previously established usage.  So new features (like a modified
> > weight function) should always be introduced such that they're only
> > triggered by commands that would have done nothing useful in earlier
> > versions.
> 
> That's fine - this is the reason why I suggested adding
> an additional (optional) argument to dgrid3d, which 
> allows the user to select the smoothing kernel. It would
> default to the current kernel (thus not breaking any
> existing apps), but allows users to make a different
> choice for new development.

It would be nice to have options in "set dgrid3d" to choose the gridding 
method. Nowadays, the "thin splines method" as an alternative can only be 
chosen at compile time. The run-time option would be much better.

I think this issue has been discussed long time, but it is still not 
implemented.

---
PM

Re: Suggestion for dgrid3d

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

Thanks.

I am happy to develop and send in a patch,
provided we can agree that this is a good
path forward and is likely to be adopted if
a sufficiently high-quality implementation is
available.

Best,

		Ph.



On Monday 29 October 2007 14:58, you wrote:
> > > We do consider backward compatibility a bit of a holy grail in this
> > > project.  It's always bad if a change to the program modifies the
> > > result of a previously established usage.  So new features (like a
> > > modified weight function) should always be introduced such that they're
> > > only triggered by commands that would have done nothing useful in
> > > earlier versions.
> >
> > That's fine - this is the reason why I suggested adding
> > an additional (optional) argument to dgrid3d, which
> > allows the user to select the smoothing kernel. It would
> > default to the current kernel (thus not breaking any
> > existing apps), but allows users to make a different
> > choice for new development.
>
> It would be nice to have options in "set dgrid3d" to choose the gridding
> method. Nowadays, the "thin splines method" as an alternative can only be
> chosen at compile time. The run-time option would be much better.
>
> I think this issue has been discussed long time, but it is still not
> implemented.
>
> ---
> PM

Re: Suggestion for dgrid3d

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

I just submitted a patch for dgrid3d to sourceforge.

Features:

- Fully backward compatible with the current version.
- "Thin Plate Splines" can now be chosen as run-time 
	option: 'set dgrid3d 30,30 splines'
- Five new smoothing kernels (gauss, cauchy, exp, 
	box, hann) which can be selected as part 
	of 'set dgrid3d'. For these kernels, the smoothing
	"radius" can be selected as part of the 
	"set dgrid3d" command.

The patch also includes updates to gnuplot.doc.

Let me know what you think.

Best,

		Ph.




On Sunday 21 October 2007 08:46, 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
>
> 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
> 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.
> 4) no way to control the "radius of influence" or
> 	catchment area for data points
>
> Suggestion:
> ========
> I think it would be desirable to have a weight function
> with the following properties:
> 1) bounded
> 2) w( d=0 ) = 1
> 3) falling smoothly as d -> infty
> 4) have a parameter which smoothly controls the
> 	size of the "catchment radius".
>
> A Gaussian is the first thing that comes to mind.
>
> I have tried it and quite like the results. I have
> posted some example images comparing Gaussian
> weighting vs the power law weighting at:
> 	www.philipp-janert.com/gnuplot
>
> Optional:
> ======
> I have hijacked the "norm" parameter to
> control the width of the Gaussian. This is
> not ideal - a better solution would be to
> extend the dgrid3d option in such a way
> that it can take two float values (instead
> of an int), which can be used to scale the
> x- and y-distances independently.
>
> Attached, you will find a patch file (against
> CVS head) containing the changes to use
> a Gaussian instead of a power law. They
> do not include the "optional" feature
> mentioned above.
>
> Please let me know what you think. I have
> not prepared a patch to the documentation
> yet - I'd like to hear opinions on this
> suggestion first.
>
> Best,
>
> 		Ph.