[Rd] bug (PR#13570)

[Duncan Murdoch]

On 3/5/2009 7:10 AM, Prof Brian Ripley wrote:
> Undortunately the example is random, so not really reproducible (and I 
> see nothing wrong on my Mac). However, Linux valgrind on R-devel is 
> showing a problem:

I can reproduce it using y <- sin(x) instead of rnorm(100), on R-patched 
(not R-devel).


> 
> ==3973== Conditional jump or move depends on uninitialised value(s)
> ==3973==    at 0xD76017B: ehg141_ (loessf.f:532)
> ==3973==    by 0xD761600: lowesa_ (loessf.f:769)
> ==3973==    by 0xD736E47: loess_raw (loessc.c:117)

I don't see why there would be errors at those spots, but I did try 
tracing into loessf.f, and it's really a maze of code.  In case someone 
wants to follow up, it looks as though the ehg128 function returns a 
garbage value on the first call.  Working backwards through it, this is 
because the local variable s is garbage, because g(0,1) (an array, not a 
function call) is garbage at line 957, which is because it got set as 
garbage somewhere between being initialized at line 918, and line 957.
I think the problem happened at lines 950/951, but I didn't follow up to 
see why.


> 
> (The uninitiialized value is in someone else's code and I suspect it 
> was either never intended to work or never tested.)  No essential 
> change has been made to the loess code for many years.
> 
> I would not have read the documentation to say that degree = 0 was a 
> reasonable value. It is not to my mind 'a polynomial surface', and 
> loess() is described as a 'local regression' for degree 1 or 2 in 
> the reference.  So unless anyone wants to bury their heads in that 
> code I think a perfectly adequate fix would be to disallow degree = 0.
> (I vaguely recall debating allowing in the code ca 10 years ago.)

I agree that's the best solution.

Duncan Murdoch

> 
> On Thu, 5 Mar 2009, Uwe Ligges wrote:
> 
>> Berwin A Turlach wrote:
>>> G'day Peter,
>>> 
>>> On Thu, 05 Mar 2009 09:09:27 +0100
>>> Peter Dalgaard <p.dalgaard at biostat.ku.dk> wrote:
>>> 
>>>> rhafen at stat.purdue.edu wrote:
>>>>> <<insert bug report here>>
>>>>> 
>>>>> This is a CRITICAL bug!!!  I have verified it in R 2.8.1 for mac
>>>>> and for windows.  The problem is with loess degree=0 smoothing.
>>>>> For example, try the following:
>>>>> 
>>>>> x <- 1:100
>>>>> y <- rnorm(100)
>>>>> plot(x, y)
>>>>> lines(predict(loess(y ~ x, degree=0, span=0.5)))
>>>>> 
>>>>> This is obviously wrong.
>>>> Obvious? How? I don't see anything particularly odd (on Linux).
>>> 
>>> Neither did I on linux; but the OP mentioned mac and windows. 
>>> On windows, on running that code, the lines() command added a lot of
>>> vertical lines; most spanning the complete window but some only part. 
>>> Executing the code a second time (or in steps) gave sensible
>>> results. 
>>> My guess would be that some memory is not correctly allocated or
>>> initialised.  Or is it something like an object with storage mode
>>> "integer" being passed to a double?  But then, why doesn't it show on
>>> linux?
>>> 
>>> Happy bug hunting.  If my guess is correct, then I have no idea how to
>>> track down such things under windows.....
>>> 
>>> Cheers,
>>>
>>> 	Berwin
>>> 
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>> Please can you folks try under R-devel (to be R-2.9.0 in a couple of weeks) 
>> and report if you still see it. I do not under R-devel (but do under 
>> R-release), so my guess is that something called by loess() has been fixed in 
>> the meantime.
>>
>> Moreover it is not the plot stuff that was wrong under R-2.8.1 (release) but 
>> the loess computations.
>>
>> Uwe Ligges
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>