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

[Duncan Murdoch]

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


>> 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
>>
>>   
> 
>