From Rob.Hyndman at buseco.monash.edu.au  Sun Apr 27 12:15:23 2008
From: Rob.Hyndman at buseco.monash.edu.au (Rob Hyndman)
Date: Sun, 27 Apr 2008 20:15:23 +1000
Subject: [Rd] median methods
In-Reply-To: <alpine.LFD.1.10.0804262134390.22028@gannet.stats.ox.ac.uk>
References: <905db6ff0804260546u5adf592cs190b914d09750ea9@mail.gmail.com>
	<alpine.LFD.1.10.0804262134390.22028@gannet.stats.ox.ac.uk>
Message-ID: <905db6ff0804270315j125d80b6y46338ce5dab10eee@mail.gmail.com>

Brian. The example I have in mind is for functional data where there
are several ways to define a median. For example, it can be defined as
the pointwise median of a set of functions {f_j(x); j=1,...,n}. Or it
can be defined as m(x) = arg min_{g(x)} \sum_j |g(x) - f_j(x)| dx. The
latter can be calculated using several different algorithms, one of
which is the Hossjer-Croux algorithm.  So I want to write a function
of the form

median.fd <- function(x, method=c("hossjer-croux","pointwise"))

where x is of class "fd" (functional data). Without a ... argument in
the generic median function, I can't do this.

There are no doubt other similar examples where an additional argument
(or more) is required.

Furthermore, this would make it consistent with mean() and quantile().

You can easily retain existing code by defining generic median as
median(x,...). Then if an na.rm argument is passed without name, it
will go through to median.default(x,na.rm) without a hitch.  It should
not affect existing methods since they must all have na.rm as a second
argument also.

So I am suggesting median(x, ...) which makes it more flexible for
method writers, and I don't think it causes a problem for existing
code.

Best wishes,
Rob



On 27/04/2008, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
> On Sat, 26 Apr 2008, Rob Hyndman wrote:
>
>
> >  Can we please have a ... argument in median() to make it possible to pass
> >  arguments to specific methods.
> >
>
>  Not without a reasoned case -- see 'Writing R Extensions' as to why it is a non-trivial change that affects all existing methods (and there are some) -- also S4 setMethod("median") calls (which there are too).
>
>  There is also an argument as to where the ... should come -- probably
>
>  function (x, ..., na.rm = FALSE)
>
>  (but that could break some existing calls), and why should na.rm be on the generic as well (it is not for mean nor quantile, for example)?
>
>  So there have to be some pretty compelling arguments in favour.
>
>
>  --
>  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
>



-- 
_____________________________
Rob J Hyndman
Professor of Statistics, Monash University
Editor-in-Chief, International Journal of Forecasting
http://www.robhyndman.info/



[Rd] median methods
Rob Hyndman