[Rd] Is there an implementation of loess with more than 3 parametric ...
Ben Bolker
bbolker at gmail.com
Mon Jun 27 17:19:55 CEST 2011
Dr. D. P. Kreil (Boku <David.Kreil <at> boku.ac.at> writes:
>
> Dear John,
>
> > I suggest that you look at the abilities of the mgcv package.
> > There are notes of mine at
> >
> > http://www.maths.anu.edu.au/%7Ejohnm/r-book/xtras/autosmooth.pdf
> >
> > that may help you get started.
>
> Thank you very much for the suggestion and the link to your write-up,
> it was indeed very helpful!
>
> I have experimented with this library for a while now and am really
> happy about its flexibility. For my immediate applied problem, I will
> now go with a gam fit ("z~te(x,y)+fa-1").
>
> I note, however, that this is much, much slower than loess, and is
> thus limited to smaller numbers of data points. (I could not fit the
> full model to 50,000 data points in a reasonable time.)
> I am therefore wondering if you knew of a way of also fixing the
> implementation of loess in R?
>
> >From the error message (recompile with larger d2MAX) it seems that the
> underlying Fortran library was perfectly happy to fit a larger number
> of parametric variables. So is there a way one could remove the
> restriction to 4 parameters in the R interface/compilation? I have not
> found an obvious place where d2MAX is defined or configured, I suspect
> it might be hard-coded...
>
If you go looking for d2MAX in the R code (i.e. download the entire
source or get a copy of the SVN tree) you will proceed as follows:
find . -name "*.c" -exec grep -l d2MAX {} \;
takes you to ./src/library/stats/src/loessc.c
Looking therein finds:
case 105:MSG("k>d2MAX in ehg136. Need to recompile with increased dimensions.")
grep 105 *.f finds loessf.f
within which we find two lines (1240 and 1361)
if(k .gt. 15) call ehg182(105)
Searching for "15" then finds a *lot* of places where "15" is
hardcoded in the file.
To modify the file you could either blindly change all the hard-coded
"15" dimensions to something larger and hope that it worked (i.e., use
a good test suite to make sure you didn't screw something up) or dig
through the code and understand it in detail to know what should
be changed ...
More information about the R-devel
mailing list