[Rd] suggested modification to the 'mle' documentation?

[Gabor Grothendieck]

On Dec 7, 2007 8:43 AM, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> On 12/7/2007 8:10 AM, Peter Dalgaard wrote:
> > Ben Bolker wrote:
> >>   At this point I'd just like to advertise the "bbmle" package
> >> (on CRAN) for those who respectfully disagree, as I do, with Peter over
> >> this issue.  I have added a data= argument to my version
> >> of the function that allows other variables to be passed
> >> to the objective function.  It seems to me that this is perfectly
> >> in line with the way that other modeling functions in R
> >> behave.
> >>
> > This is at least cleaner than abusing the "fixed" argument. As you know,
> > I have reservations, one of which is that it is not a given that I want
> > it to behave just like other modeling functions, e.g. a likelihood
> > function might refer to more than one data set, and/or data that are not
> > structured in the traditional data frame format. The design needs more
> > thought than just adding arguments.
>
> We should allow more general things to be passed as data arguments in
> cases where it makes sense.  For example a list with names or an
> environment would be a reasonable way to pass data that doesn't fit into
> a data frame.
>
> > I still prefer a design based a plain likelihood function. Then we can
> > discuss how to construct such a function so that  the data are
> > incorporated in a flexible way.  There are many ways to do this, I've
> > shown one, here's another:
> >
> >> f <- function(lambda) -sum(dpois(x, lambda, log=T))
> >> d <- data.frame(x=rpois(10000, 12.34))
> >> environment(f)<-evalq(environment(),d)
>
> We really need to expand as.environment, so that it can convert data
> frames into environments.  You should be able to say:
>
> environment(f) <- as.environment(d)
>
> and get the same result as
>
> environment(f)<-evalq(environment(),d)
>
> But I'd prefer to avoid the necessity for users to manipulate the
> environment of a function.  I think the pattern
>
> model( f, data=d )
>
> being implemented internally as
>
> environment(f) <- as.environment(d, parent = environment(f))
>
> is very nice and general.  It makes things like cross-validation,
> bootstrapping, etc. conceptually cleaner:  keep the same
> formula/function f, but manipulate the data and see what happens.
> It does have problems when d is an environment that already has a
> parent, but I think a reasonable meaning in that case would be to copy
> its contents into a new environment with the new parent set.
>
> Duncan Murdoch

Something close to that is already possible in proto and its cleaner in proto
since the explicit environment manipulation is unnecessary as it occurs
implicitly:

1. In terms of data frame d from Peter Dalgaard's post the code
below is similar to my last post but it replaces the explicit
manipulation of f's environemnt with the creation of proto object
p on line ###.  That line converts d to an anonymous proto object
containing the components of d, in this case just x, and then
creates a child object p which can access x via delegation/inheritance.

library(proto)
set.seed(1)
f <- function(lambda) -sum(dpois(x, lambda, log=T))
d <- data.frame(x=rpois(100, 12.34))
p <- proto(as.proto(as.list(d)), f = f) ###
mle(p[["f"]], start=list(lambda=10))

2. Or the ### line could be replaced with the following line
which places f and the components of d, in this case just x,
directly into p:

p <- proto(f = f, envir = as.proto(as.list(d)))

again avoiding the explicit reset of environment(f) and the evalq.

>
>
> >> mle(f, start=list(lambda=10))
> >
> > Call:
> > mle(minuslogl = f, start = list(lambda = 10))
> >
> > Coefficients:
> >  lambda
> > 12.3402
> >
> > It is not at all an unlikely design to have mle() as a generic function
> > which works on many kinds of objects, the default method being
> > function(object,...) mle(minuslogl(obj)) and minuslogl is an extractor
> > function returning (tada!) the negative log likelihood function.
> >>   (My version also has a cool formula interface and other
> >> bells and whistles, and I would love to get feedback from other
> >> useRs about it.)
> >>
> >>    cheers
> >>     Ben Bolker
> >>
> >>
> >
> >
>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>