On Wed, 21 Jan 2004, Martin Maechler wrote: > >>>>> "Greg" == Warnes, Gregory R <[EMAIL PROTECTED]> > >>>>> on Wed, 21 Jan 2004 01:48:15 -0500 writes: > > Greg> As I've mentioned a number of times. I find it very > Greg> useful to have lowess() become a generic function so > Greg> that a lowess.formula() can be defined. > > Greg> Below is a patch that makes both changes, as well as > Greg> updating the corresponding help documentation. > > I think most times you mentioned this, Brian told you that > "loess" was there and was generic and was to be recommended over > lowess anyway.
Not quite: loess() is not generic, but it does have a formula interface and it was recommended over lowess() by the authors of both. (loess() is not generic for the reasons I sketch below.) > Hence I think we should hear reasons why lowess is to be > preferred to loess in some cases. > [and I think I may well support your argument; I've forgotten > which reasons I thought to have in the past when deciding for > lowess (against loess).] > > *Not* making lowess generic is one way to recommend loess ;-) It seems to me only to be worth making functions generic if they are likely to be extended in unforeseen ways: making image() generic was one of those. For lowess, the only plausible methods are for formula and vector, so why not just write a wrapper called lowessForm? I took the same approach when re-implementing loess: it could have had a matrix + vector interface but it did not seem worth setting up a generic just for that. -- Brian D. Ripley, [EMAIL PROTECTED] 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 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
