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