From bbolker at gmail.com  Wed Feb 23 21:38:52 2011
From: bbolker at gmail.com (Ben Bolker)
Date: Wed, 23 Feb 2011 15:38:52 -0500
Subject: [Rd] request for patch in  "drop1" (add.R)
In-Reply-To: <19813.27676.462859.988544@stat.math.ethz.ch>
References: <4D65164D.7080707@mcmaster.ca>
	<19813.27676.462859.988544@stat.math.ethz.ch>
Message-ID: <4D65705C.90408@gmail.com>

On 11-02-23 03:20 PM, Martin Maechler wrote:
>>>>>> Ben Bolker <bbolker at gmail.com>
>>>>>>     on Wed, 23 Feb 2011 09:14:37 -0500 writes:
> 
>     >   By changing three lines in drop1 from access based on $
>     > to access based on standard accessor methods (terms() and
>     > residuals()), it becomes *much* easier to extend drop1 to
>     > work with other model types.  The use of $ rather than
>     > accessors in this context seems to be an oversight rather
>     > than a design decision, but maybe someone knows better ...
> 
>     >   In particular, if one makes these changes (which I am
>     > pretty certain will not break anything, as the original
>     > code basically mimicked the default methods anyway), it
>     > becomes possible to make drop1() work with mer objects
>     > (Doug Bates's new mixed model code) merely by defining:
> 
>     > terms.mer <- function(x, ...) {
>     > attr(x at frame,"terms")
>     > }
> 
>     > extractAIC.default <- function(fit, scale=0, k=2, ...) {
>     > L <- logLik(fit)
>     > edf <- attr(L,"df")
>     > c(edf,-2*L+2*edf)
>     > }
> 
>     > Adding this definition of extractAIC.default also makes drop1() work
>     > with lme fits ...
> 
>     > Comments?  Should I submit to the bug database as "enhancement
>     > request"?  Are there any hidden downsides to this?
> 
> drawback: a possible very small performance cut for the cases
> where the "$" access is ok.  But that should not count.
> 
> I like the idea.... {it's a pity that only S3 methods work that way,
> because residuals(), terms(), etc... are unfortunately not
> general (implicit) S4 generics but just S3 ones..
> 
> I'm currently testing your change, plus some more in step().
> However, for step() to work automagically there is more needed.
> It currently relies in more places on 'object' being a list to
> which you can append new components, basically by
>    fit <- object
>    fit$new1 <- ...
>    fit$new2 <- ...
> 
> That would have to be changed to something like
>    fit <- list(obj = object)
>    fit$new1 <- ...
>    fit$new2 <- ...
> and more changes where 'fit' has to be replaced by 'fit$obj'.
> Would that not be of interest as well?
> 
> Martin

  Potentially, but I am personally much more interested in enabling
drop1(), which seems to be a much more legitimate tool for testing terms
in models than step(), which is so easy to abuse ...

    Ben Bolker



[Rd] request for patch in "drop1" (add.R)
Ben Bolker