[R] Bug in lowess

Frank E Harrell Jr f.harrell at vanderbilt.edu
Fri Oct 13 14:50:47 CEST 2006


Prof Brian Ripley wrote:
> Frank Harrell wrote:
> 
> [...]
> 
>> Thank you Brian.  It seems that no matter what is the right answer, the
>> answer currently returned on my system is clearly wrong.  lowess()$y
>> should be constrained to be within range(y).
> 
> Really?  That assertion is offered without proof and I am pretty sure is 
> incorrect.  Consider
> 
>> x <- c(1:10, 20)
>> y <- c(1:10, 5) + 0.01*rnorm(11)
>> lowess(x,y)
> $x
>  [1]  1  2  3  4  5  6  7  8  9 10 20
> 
> $y
>  [1]  0.9983192  1.9969599  2.9960805  3.9948224  4.9944158  5.9959855
>  [7]  6.9964400  7.9981434  8.9990607 10.0002567 19.9946117
> 
> Remember that lowess is a local *linear* fitting method, and may give 
> zero weight to some data points, so (as here) it can extrapolate.

Brian - thanks - that's a good example though not typical of the kind I 
see from patients.

> 
> After reading what src/appl/lowess.doc says should happen with zero 
> weights, I think the answer given on Frank's system probably is the 
> correct one.  Rounding error is determining which of the last two points 
> is given zero robustness weight: on a i686 system both of the last two 
> are, and on mine only the last is. As far as I can tell in 
> infinite-precision arithmetic both would be zero, and hence the value at 
> x=120 would be found by extrapolation from those (far) to the left of it.
> 
> I am inclined to think that the best course of action is to quit with a 
> warning when the MAD of the residuals is effectively zero.  However, we 
> need to be careful not to call things 'bugs' that we do not understand 
> well enough.  This might be a design error in lowess, but it is not 
> AFAICS a bug in the implementation.

Yes it appears to be a weakness in the underlying algorithm.

Thanks
Frank



More information about the R-help mailing list