bug (PR#13570)
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