[Rd] overhaul of mle

[Roger D. Peng]

Taking advantage of lexical scoping is definitely the way to go 
here.  I usually write a function called `makeLogLik' or 
something like that which basically returns a function that can 
be passed into an optimizer.  Something like:

makeLogLik <- function(X=Xdefault, Y=Ydefault, Z=Zdefault) {
	function(par1, par2, par3) {
		...
	}
}

-roger

Peter Dalgaard wrote:

> Ben Bolker <bolker at zoo.ufl.edu> writes:
> 
>  
> 
>>    OK, I want to hear about this.  My normal approach to writing
>>likelihood functions that can be evaluated with more than one data
>>set is essentially
>>
>>mll <- function(par1,par2,par3,X=Xdefault,Y=Ydefault,Z=Zdefault) { ... }
>>
>>where X, Y, Z are the data values that may change from one fitting
>>exercise to the next.  This seems straightforward to me, and I always
>>thought it was the reason why optim() had a ... in its argument list,
>>so that one could easily pass these arguments down.  I have to confess
>>that I don't quite understand how your paradigm with with() works: if
>>mll() is defined as you have it above, "data" is a data frame containing
>>$x and $y, right?  How do I run mle(minuslogl=mll,start=...) for
>>different values of "data" (data1, data2, data3) in this case?  Does
>>it go in the call as mle(minuslogl=mll,start=...,data=...)?  Once I've
>>found my mle, how do I view/access these values when I want to see
>>what data I used to fit mle1, mle2, etc.?
> 
> 
> You generate different likelihood functions. If you do it using
> lexical scoping, the data is available in the environment(mll). If you
> insist on having one function that can be modified by changing data, you
> can simply assign into that environment.
>  
> 
>>   I'm willing to change the way I do things (and teach my students
>>differently), but I need to see how ... I don't see how what I've
>>written is an "abuse" of the fixed arguments [I'm willing to believe
>>that it is, but just don't know why]
> 
> 
> "Abuse" is of course a strong word, but...
> 
> The point is that likelihood inference views the likelihood as a
> function of the model parameters *only* and it is useful to stick to
> that concept in the implementation. The fixed arguments were only ever
> introduced to allow profiling by keeping some parameters fixed during
> optimization. 
> 
> Another aspect is that one of my ultimate goals with this stuff was to
> allow generic operations to be defined on likelihoods (combining,
> integrating, mixing, conditioning...) and that becomes even more
> elusive if you have to deal with data arguments for the component
> likelihoods. Not that I've got very far thinking about the design, but
> I'm rather sure that the "likelihood object" needs to be well-defined
> if it is to have a chance at all.
> 
> 
>>>Hmm.. I see the effect with the current version too. Depending on
>>>temperament, it is the labels rather than the order that is wrong...
>>
>>   Hmmm.  By "current version" do you mean you can still
>>find ways to get wrong answers with my modified version?
>>Can you send me an example?  Can you think of a better way to fix this?
> 
> 
> Strike "too", haven't gotten around to checking your code yet.
> Possibly, this requires a bug fix for 1.9.1.
>