Re: Is this a bug in "smooth cnorm" ?

[Daniel J S. <dan...@ie...>]

On 10/07/2015 11:42 PM, sfeam wrote:
> In the file interpol.c is this chunk of code starting at line 1264:
>
> %%%%
>
> if (k) {
>
> cp->points[j].x = x;
>
> if ( cp->plot_smooth == SMOOTH_FREQUENCY ||
>
> cp->plot_smooth == SMOOTH_CUMULATIVE ||
>
> cp->plot_smooth == SMOOTH_CUMULATIVE)
>
> k = 1;
>
> cp->points[j].y = y /= (double) k;
>
> %%%%
>
> This is clearly not correct, but I cannot figure out if the
>
> error is a duplicate test for SMOOTH_CUMULATIVE or a missing
>
> test for SMOOTH_CUMULATIVE_NORMALISED.
>
> The code was added in Apr 2010 as part of the new smooth option
>
> "smooth cnormal". Because this was clearly intended as part
>
> of the new option, my first thought is that it's a typo and
>
> the 3rd test should be for SMOOTH_CUMULATIVE_NORMALISED.
>
> But I cannot find any test case where the current code produces
>
> an error, so maybe the test is not really needed at all?
>
> Can someone figure out what the intent was, and whether there
>
> has always been a bug in "smooth cnormal"?

My guess would be that it should be SMOOTH_CUMULATIVE_NORMALISED.  In 
plot2d.c

		/* create new data set by evaluation of
		 * interpolation routines */
[snip]
		case SMOOTH_FREQUENCY:
		case SMOOTH_CUMULATIVE:
		case SMOOTH_CUMULATIVE_NORMALISED:
		    gen_interp_frequency(this_plot);
		    break;

so it seems these three go together.

Even if there is a "cnormal" smoothing example in the demos, it might 
not fail because there is a possibility that k is already 1 for some 
reason or another.  Look at the conditional statement in interpol.c and 
k starts out as 0.  In the first pass if !k then k is set to 1 along 
with some other code.  So at that point k is 1 and if there is another 
pass and the middle condition is not met then k is already 1 for the 
SMOOTH_CUMULATIVE_NORMALISED test.  So, the bug doesn't manifest in that 
scenario.

What needs to happen is that middle condition occurs so that k++ 
increments past 1 and then "case SMOOTH_CUMULATIVE_NORMALISED:" occurs 
on the next pass.  That might be an unlikely scenario, don't know.

Dan