I was working on a permutation-like variant of the bootstrap for smaller
samples, and wanted to be able to get summary stats of my estimator
conveniently. mean() is OK as its a generic, so a mean.oddboot function gets
used automatically. But var, sd and others are not originally written as
generic; they have to be explicitly masked by a package or new declaration.
It would have been nice if stats::var was a generic to make it more easily
extensible... one for the wish list?
Steve Ellison
*******************************************************************
This email and any attachments are confidential. Any use, co...{{dropped}}
On Wed, 9 May 2007, S Ellison wrote:> I was working on a permutation-like variant of the bootstrap for smaller > samples, and wanted to be able to get summary stats of my estimator > conveniently. mean() is OK as its a generic, so a mean.oddboot function > gets used automatically. But var, sd and others are not originally > written as generic; they have to be explicitly masked by a package or > new declaration. > > It would have been nice if stats::var was a generic to make it more > easily extensible... one for the wish list?There is a reason: does your version have exactly the semantics of the function in stats (which does more than compute a variance)? If we make functions generic, we rely on package writers implementing the documented semantics (and that is not easy to check). That was deemed to be too easy to get wrong for var(). -- 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
Brian,>If we make functions generic, we rely on package writers implementing the documented >semantics (and that is not easy to check). That was deemed to be too >easy to get wrong for var().Hard to argue with a considered decision, but the alternative facing increasing numbers of package developers seems to me to be pretty bad too ... There are two ways a package developer can currently get a function tailored to their own new class. One is to rely on a generic function to launch their class-specific instance, and write only the class-specific instance. That may indeed be hard to check, though I would be inclined to think that is the package developer's problem, not the core team's. But it has (as far as I know today ...?) no wider impact. The other option, with no existing generic, is to mask the original function by writing a new generic function that respects the original syntax exactly, and then implement a fun.default that replicates the original non-generic function's behaviour, hopefully by calling it directly. As an example, library(circular) masks stats::var, though I'm fairly sure its not the only case. This has obvious disadvantages, including potentially system-wide (R-wide at least!) impact and unfavourable interactions between packages masking each other's generics and defaults). I will use masking if I have to, at least for my own local use where its only me that suffers if (when?) I get it wrong. But the idea makes me very nervous, especially if I imagine folk who _don't_ get as nervous at the idea. Hence the feeling that wider use of generics for fundamental and common functions might make for a safer world. Steve E ******************************************************************* This email and any attachments are confidential. Any use, co...{{dropped}}
The vcov function in package stats is already a generic, could you write your methods for vcov rather than for var? -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.snow at intermountainmail.org (801) 408-8111> -----Original Message----- > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of S Ellison > Sent: Wednesday, May 09, 2007 4:02 AM > To: r-devel at r-project.org > Subject: [Rd] One for the wish list - var.default etc > > I was working on a permutation-like variant of the bootstrap > for smaller samples, and wanted to be able to get summary > stats of my estimator conveniently. mean() is OK as its a > generic, so a mean.oddboot function gets used automatically. > But var, sd and others are not originally written as generic; > they have to be explicitly masked by a package or new declaration. > > It would have been nice if stats::var was a generic to make > it more easily extensible... one for the wish list? > > Steve Ellison > > ******************************************************************* > This email and any attachments are confidential. Any use,\...{{dropped}}