[Rd] overhaul of mle

Peter Dalgaard p.dalgaard at biostat.ku.dk
Sat Jun 12 02:20:22 CEST 2004


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.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: (+45) 35327907



More information about the R-devel mailing list