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