Menu
▾
▴
gnuplot-beta
|
From: Clement L. <the...@gm...> - 2012-10-04 14:37:19
|
Hello, I've written a small patch[a] that adds a harmonic mean function[1] to pm3d corners2color. I've pasted into this private pastebin because the mailing list seems to chomp up my attachment. The correct usages of this harmonic mean is syntactically identical to, say, if you wanted to use geometrical mean (geomean): set pm3d corners2color harmean The reason why I added another 'mean' function is to complete the set. Gnuplot at the moment as two of the three 'pythagorean means'[2]. The harmonic mean is useful as it can offer a truer sense of the average. See this physics example [3]. One question I have is that the harmonic mean is not defined for numbers less than or equal to 0. Should I have harmean4() return 0 in these cases? I hope it's acceptable, I've never written a patch for any open source software before. Clement Law [a] http://rifers.org/paste/harmean/show/1883 [1] http://en.wikipedia.org/wiki/Harmonic_mean [2] http://en.wikipedia.org/wiki/Pythagorean_means [3] http://en.wikipedia.org/wiki/Harmonic_mean#Physics |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-10-04 17:20:53
|
On Thursday, 04 October 2012, Clement Law wrote:
> Hello,
>
> I've written a small patch[a] that adds a harmonic mean function[1] to
> pm3d corners2color. I've pasted into this private pastebin because the
> mailing list seems to chomp up my attachment.
Got it, thanks.
It looks straightforward and can go into CVS after testing.
Just a note for the future:
That pastebin interface is atrocious.
All I can manage to extract from it is a 20K+ line dump of every
difference in your build tree, regardless of whether it's relevant
to the harmonic mean patch or just CVS tracking cruft. Because it
was obvious that the work as described should only touch
pm3d/set/save/show, I was able to poke around with an editor to
extract what I needed but it was painful.
diff -ur cvs/gnuplot/src/ mytree/gnuplot/src
would produce a far more usable patch.
> The correct usages of this harmonic mean is syntactically identical
> to, say, if you wanted to use geometrical mean (geomean):
>
> set pm3d corners2color harmean
>
> The reason why I added another 'mean' function is to complete the set.
> Gnuplot at the moment as two of the three 'pythagorean means'[2]. The
> harmonic mean is useful as it can offer a truer sense of the average.
> See this physics example [3].
>
> One question I have is that the harmonic mean is not defined for
> numbers less than or equal to 0. Should I have harmean4() return 0 in
> these cases?
>
> I hope it's acceptable, I've never written a patch for any open source
> software before.
>
> Clement Law
>
> [a] http://rifers.org/paste/harmean/show/1883
> [1] http://en.wikipedia.org/wiki/Harmonic_mean
> [2] http://en.wikipedia.org/wiki/Pythagorean_means
> [3] http://en.wikipedia.org/wiki/Harmonic_mean#Physics
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
|
|
From: <pl...@pi...> - 2012-10-06 10:27:15
|
On 10/04/12 16:37, Clement Law wrote: > One question I have is that the harmonic mean is not defined for > numbers less than or equal to 0. Should I have harmean4() return 0 in > these cases? > > I hope it's acceptable, I've never written a patch for any open source > software before. > > Clement Law If the value is not defined then it should probably return NaN rather than zero , which would be an incorrect result. Presumably physical data where this is the appropriate mean would only go zero or negative if there was an error in the data. I can see that this mean would be a useful addition. Thanks, Peter. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-10-06 17:03:42
|
On Friday, 05 October 2012, pl...@pi... wrote: > On 10/04/12 16:37, Clement Law wrote: > > One question I have is that the harmonic mean is not defined for > > numbers less than or equal to 0. Should I have harmean4() return 0 in > > these cases? > > > > Clement Law > > If the value is not defined then it should probably return NaN rather > than zero , which would be an incorrect result. > > Presumably physical data where this is the appropriate mean would only > go zero or negative if there was an error in the data. > > Thanks, Peter. I agree. However, the pm3d code currently treats NaN as if it were zero anyhow, so as a practical matter the plot would not come out any different. The "with image" plot modes recognize NaN and do not draw the corresponding rectangular pixel. Should we make pm3d do the same? I haven't looked to see how much work that would be. Ethan |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-10-06 22:56:41
|
On Thursday, 04 October 2012, Clement Law wrote: > I've written a small patch[a] that adds a harmonic mean function[1] to > pm3d corners2color. > > set pm3d corners2color harmean > > The reason why I added another 'mean' function is to complete the set. > Gnuplot at the moment as two of the three 'pythagorean means'[2]. The > harmonic mean is useful as it can offer a truer sense of the average. > See this physics example [3]. > > Clement Law I have a related question. There is an option "set pm3d interpolate <xdelta>,<ydelta>" that produces smoother coloring subdividing each quadrangle into smaller quadrangles with individually calculated color values. But these color values are always assign by linear interpolation. For color schemes c1/c2/c3/c4/mean this comes out equivalent to the same overall coloring applied to a finer grid of x,y values. The finer the interpolation, the closer it comes to a true linear color gradient. However, for color schemes using the harmonic or geometric mean, the finer grid still results in a linear color gradient rather than the requested geometric or harmonic color variation. Shouldn't the interpolation in these cases be some non-linear function? What function would that be? Ethan |
|
From: Petr M. <mi...@ph...> - 2012-10-07 19:27:28
|
> However, the pm3d code currently treats NaN as if it were zero anyhow, > so as a practical matter the plot would not come out any different. > > The "with image" plot modes recognize NaN and do not draw the corresponding > rectangular pixel. Should we make pm3d do the same? > I haven't looked to see how much work that would be. Isn't it gnuplot who does not read it properly? I have tried set view map; splot 'a.dat' with pm3d and plot 'a.dat' with image with 0 0 0 0 1 -1 0 2 -4 0 3 -9 1 0 1 1 1 0 1 2 -3 1 3 -8 2 0 4 2 1 3 2 2 0 2 3 -5 3 0 9 3 1 8 3 2 NaN 3 3 9 and it was the pm3d style which skipped the point, not the image style -- thus the opposite observation. --- Petr |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-10-08 00:04:02
|
On Sunday, 07 October 2012, Petr Mikulik wrote:
> > However, the pm3d code currently treats NaN as if it were zero anyhow,
> > so as a practical matter the plot would not come out any different.
> >
> > The "with image" plot modes recognize NaN and do not draw the corresponding
> > rectangular pixel. Should we make pm3d do the same?
> > I haven't looked to see how much work that would be.
>
> I have tried
> set view map; splot 'a.dat' with pm3d
> and
> plot 'a.dat' with image
> and it was the pm3d style which skipped the point, not the image style -- thus
> the opposite observation.
Very interesting. Those were not the test cases I tried.
For image plots I had in mind the examples in 'imageNaN.dem',
which plot using the commands
plot $matrixdata matrix with image # NaN pixel is omitted
set view map
splot $matrixdata matrix with image # NaN pixel is omitted
While for the pm3d plots I used the last plot in "pm3d.dem"
after modifying Dima's new harmean4() function to return NaN
when appropriate.
You are absolutely right that the simpler non-matix
'plot with image' command also needs fixing.
> Isn't it gnuplot who does not read it properly?
It seems so.
Image data is read properly in matrix mode but not (it seems)
in non-matrix mode.
I do not understand why your pm3d example works but mine
does not. From inspection of the code in pm3d.c I see no
special case for NaN pixel values, so how does it ever work?
I had been thinking that a new test would be needed,
like this:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -911,10 +914,11 @@ pm3d_plot(struct surface_points *this_pl
if (pm3d.direction != PM3D_DEPTH) {
if (color_from_rgbvar)
- set_rgbcolor(gray);
+ set_rgbcolor((unsigned int)gray);
else
set_color(gray);
- filled_quadrangle(corners);
+ if (!isnan(gray))
+ filled_quadrangle(corners);
} else {
/* copy quadrangle */
quadrangle* qp = quadrangles + current_quadrangle;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Yet your example works even without this change. How?
Clearly I need to stare at this some more.
Ethan
> with
>
> 0 0 0
> 0 1 -1
> 0 2 -4
> 0 3 -9
>
> 1 0 1
> 1 1 0
> 1 2 -3
> 1 3 -8
>
> 2 0 4
> 2 1 3
> 2 2 0
> 2 3 -5
>
> 3 0 9
> 3 1 8
> 3 2 NaN
> 3 3 9
>
>
> ---
> Petr
>
|
|
From: Petr M. <mi...@ph...> - 2012-10-07 19:44:16
|
> There is an option "set pm3d interpolate <xdelta>,<ydelta>" that > produces smoother coloring subdividing each quadrangle into smaller > quadrangles with individually calculated color values. But these > color values are always assign by linear interpolation. > > For color schemes c1/c2/c3/c4/mean this comes out equivalent to the > same overall coloring applied to a finer grid of x,y values. The > finer the interpolation, the closer it comes to a true linear color > gradient. > > However, for color schemes using the harmonic or geometric mean, > the finer grid still results in a linear color gradient rather than > the requested geometric or harmonic color variation. Shouldn't the > interpolation in these cases be some non-linear function? > What function would that be? Coordinates x, y can be interpolated linearly, but the colour coords can follow arithmentic, geometric or harmonic mean. --- Petr |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-10-15 05:31:26
|
On Sunday, 07 October 2012, Petr Mikulik wrote: >Ethan Merritt wrote > > > There is an option "set pm3d interpolate <xdelta>,<ydelta>" that > > produces smoother coloring subdividing each quadrangle into smaller > > quadrangles with individually calculated color values. But these > > color values are always assign by linear interpolation. > > > > For color schemes c1/c2/c3/c4/mean this comes out equivalent to the > > same overall coloring applied to a finer grid of x,y values. The > > finer the interpolation, the closer it comes to a true linear color > > gradient. > > > > However, for color schemes using the harmonic or geometric mean, > > the finer grid still results in a linear color gradient rather than > > the requested geometric or harmonic color variation. Shouldn't the > > interpolation in these cases be some non-linear function? > > What function would that be? > > Coordinates x, y can be interpolated linearly, but the colour coords can > follow arithmentic, geometric or harmonic mean. Sure, but what are the corresponding interpolation functions? If the c1/c2/c3/c4 quadrangle is to be colored using a harmonic mean, and interpolation 3,3 splits adds four new vertices in the interior, what is the proper interpolated color at those new vertices? Clement Law <the...@gm...> wrote> > I've written up another pm3d corners2color function. It works just as > the others, i.e., > set pm3d corners2color rms > rms4 takes the root mean square[1] of the four corners OK. Do you see what I'm asking about how to handle interpolation for these non-linear coloring schemes? Ethan |
