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.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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
