[Rd] bug (PR#13570)
Prof Brian Ripley
ripley at stats.ox.ac.uk
Wed Mar 11 03:57:45 CET 2009
On Tue, 10 Mar 2009, Benjamin Tyner wrote:
> Many thanks Brian for tracking this down. Was it fixed by
>
> c next line is not in current dloess
> goto 7
>
> in ehg136? If this needs to be in the netlib version as well, we should
> inform Eric Grosse.
The difference was in the argument list of one of the functions
(ehg124?). It was 'just' a question of looking at 354 diff sections,
not all of which I understood, including that commented above.
> While we're at it, there are a few more inconsistencies (not nearly as
> serious as PR#13570 so I hesitate to call them bugs) regarding the definition
> of leaf cell membership (certain .lt. should be .le. ) in ehg128, ehg137, and
> ehg138 (not currently used); it seems I neglected to mention these to Eric.
> If you are interested in these I can submit a patch and will notify Eric as
> well.
Please do let me know and I'll merge in.
> Finally, perhaps now is as good a time as any to point out that in the
> documentation, the bit about cross-terms in
>
> \item{drop.square}{for fits with more than one predictor and
> \code{degree=2}, should the quadratic term (and cross-terms) be
> dropped for particular predictors?
>
> is incorrect -- cross terms are not dropped in this implementation of loess.
Thanks, I will incorporate that.
> Thanks again,
> Ben
>
> Prof Brian Ripley wrote:
>> I've found the discrepancy, so the patched code from current dloess is now
>> available in R-patched and R-devel.
>>
>> On Fri, 6 Mar 2009, Prof Brian Ripley wrote:
>>
>>> On Thu, 5 Mar 2009, Benjamin Tyner wrote:
>>>
>>>> Hi
>>>>
>>>> Nice to hear from you Ryan. I also do not have the capability to debug on
>>>> windows; however, there is a chance that the behavior you are seeing is
>>>> caused by the following bug noted in my thesis (available on ProQuest;
>>>> email me if you don't have access):
>>>>
>>>> "When lambda = 0 there are no local slopes to aid the blending algorithm,
>>>> yet the
>>>> interpolator would still assume they were available, and thus use
>>>> arbitrary values
>>>> from memory. This had implications for both fit and tr[L] computation. In
>>>> the
>>>> updated code these are set equal to zero which seems the best automatic
>>>> rule when
>>>> lambda = 0." [lambda refers to degree]
>>>>
>>>> I submitted a bug fix to Eric Grosse, the maintainer of the netlib
>>>> routines; the fixed lines of fortran are identified in the comments at
>>>> (just search for my email address):
>>>>
>>>> http://www.netlib.org/a/loess
>>>>
>>>> These fixes would be relatively simple to incorporate into R's version of
>>>> loessf.f
>>>
>>> The fixes from dloess even more simply, since R's code is based on dloess.
>>> Thank you for the suggestion.
>>>
>>> Given how tricky this is to reproduce, I went back to my example under
>>> valgrind. If I use the latest dloess code, it crashes, but by selectively
>>> importing some of the differences I can get it to work.
>>>
>>> So it looks as if we are on the road to a solution, but something in the
>>> current version (not necessarily in these changes) is incompatible with
>>> the current R code and I need to dig further (not for a few days).
>>>
>>>> Alternatively, a quick check would be for someone to compile the source
>>>> package at https://centauri.stat.purdue.edu:98/loess/loess_0.4-1.tar.gz
>>>> and test it on windows. Though this package incorporates this and a few
>>>> other fixes, please be aware that it the routines are converted to C and
>>>> thus there is a slight performance hit compared to the fortran.
>>>>
>>>> Hope this helps,
>>>> Ben
>>>
>>> [...]
>>>
>>> --
>>> 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
>>>
>>
>
>
--
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
More information about the R-devel
mailing list