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: > > ==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) > > (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.)
The code itself has if (!match(degree, 0:2, 0)) stop("'degree' must be 0, 1 or 2") though. "Local fitting of a constant" essentially becomes kernel smoothing, right? > 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.dalga...@biostat.ku.dk> wrote: >>> >>>> rha...@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@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@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- O__ ---- Peter Dalgaard Ă˜ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel