From ripley at stats.ox.ac.uk  Thu Mar  5 13:10:20 2009
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Thu, 5 Mar 2009 12:10:20 +0000 (GMT)
Subject: [Rd] bug (PR#13570)
In-Reply-To: <49AFB412.2060807@statistik.tu-dortmund.de>
References: <20090304211010.A588D2832180@mail.pubhealth.ku.dk>
	<49AF88B7.1000002@biostat.ku.dk>
	<20090305174301.20099b11@berwin-nus1>
	<49AFB412.2060807@statistik.tu-dortmund.de>
Message-ID: <alpine.LFD.2.00.0903051121300.2646@gannet.stats.ox.ac.uk>

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.)

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
>

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] bug (PR#13570)
Prof Brian Ripley