suggested modification to the 'mle' documentation?

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:

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.  

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.