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

On Thu, 5 Mar 2009, Peter Dalgaard wrote:

> 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?

I do know the R code allows it: the question is whether it is worth 
the effort of finding the problem(s) in the underlying c/dloess code, 
whose manual (and our reference) is entirely about 1 or 2.  I am 
concerned that there may be other things lurking in the degree=0 case 
if it was never tested (in the netlib version: I am sure it was only 
minmally tested through my R interface).

I checked the original documentation on netlib and that says

29      DIM     dimension of local regression
                 1               constant
                 d+1             linear   (default)
                 (d+2)(d+1)/2    quadratic
                 Modified by ehg127 if cdeg<tdeg.

which seems to confirm that degree = 0 was intended to be allowed, and 
what I dimly recall from ca 1998 is debating whether the R code should 
allow that or not.

If left to me I would say I did not wish to continue to support degree 
= 0.

>
>
>> 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
>>>
>>
>
>
> --
>   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.dalgaard at biostat.ku.dk)              FAX: (+45) 35327907
>
>

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