From bolker at zoo.ufl.edu  Sun Jun 13 20:49:39 2004
From: bolker at zoo.ufl.edu (Ben Bolker)
Date: Mon Jun 14 20:19:33 2004
Subject: [Rd] overhaul of mle
In-Reply-To: <40CA5F08.5010604@jhsph.edu>
References: <40C8A3FE.6030102@zoo.ufl.edu>
	<x2n03ab571.fsf@biostat.ku.dk>	<40CA17AB.4090805@zoo.ufl.edu>
	<x2acz9bpa1.fsf@biostat.ku.dk> <40CA5F08.5010604@jhsph.edu>
Message-ID: <40CCA1C3.1060407@zoo.ufl.edu>

Hmmm.  I'm still struggling with this a little bit.  I do now see, I
guess, how to use lexical scoping to get the same thing accomplished
as
mll <- function(p1,p2,p3,data1,data2,data3)
[although it still seems like the long way around].

   Peter, I appreciate why you're trying to define things this narrowly,
and I agree that I've extended the use of the "fixed" arguments.  Would
it make you any happier if there were a third argument in addition to
start and fixed (say "otherargs") that allowed for other arguments?
The other possibility would be to try to allow other arguments in a ...
argument that got passed through to optim(), but that would conflict
with the way the function is defined now since right now ... is supposed
to contain additional arguments to optim() [if you wanted to
allow the use of ... you  could either (1) add
an "optimargs" argument list with arguments for optim or (2) try
to sort the ... list according to those that matched formals(optim)
and those that didn't -- either way is bit of a nuisance, I guess).

   The advantage of an "otherargs" argument is that it would provide
a way for you (Peter) to define a strict subset of the functionality
that only worked when people refrained from messing with the data --
if someone wanted to combine two likelihoods you could either check
that the "otherargs" components were identical, or disallow that
operation if "otherargs" was non-NULL.

   Again, I don't want to be a pain -- we all have our own goals and
ways of working, and I certainly don't have any intention
of hijacking the mle code (although
in the end I guess I could always fork my own version -- this is GPL,
right?).  It's just that it seems much more natural to me to do

mll <- function(p1,p2,p3,data1,data2,data3)
m1 = mle(mll,start=...,otherargs=list(data1=X1,data2=X2,data3=X3))
m2 = mle(mll,start=...,otherargs=list(data1=Y1,data2=Y2,data3=Y3))

rather than

mll <- function(p1,p2,p3) { f(p1,p2,p3,data1) }
assign("data1",X1,envir=environment(mll))
assign("data2",X2,envir=environment(mll))
assign("data3",X3,envir=environment(mll))
...
m1 = mle(mll,start=...)
assign("data1",Y1,envir=environment(mll))
assign("data2",Y2,envir=environment(mll))
assign("data3",Y3,envir=environment(mll))
m2 = mle(mll,start=...)

or

makeLogLik <- function(data1,data2,data3) {
    function(p1,p2,p3) { }
}
m1 <- mle(makeLogLik(X1,X2,X3),start=...)
m2 <- mle(makeLogLik(Y1,Y2,Y3),start=...)

[and yes, I do sometimes have three different
"data" objects, of different lengths, to use
in MLE analyses: right now I'm doing something
where I have population samples in one set
of years and fishery closures in another, different-length,
set of years -- it would be possible to combine
them all into a single data frame, but the point
is that it's not an unusual requirement to
have multiple auxiliary data sets]

   Am I making any sense here?  Do any other readers of R-devel (or at
least those that have hung on to this point) routinely run the same
MLE analyses for a variety of different data sets and find my
approach sensible, or am I alone?

   Ben

PS lm(), glm(), nls(), nlme(), ... all have a "data" argument that
seems to play the role of "otherargs" presented above.  Would this
be a sensible and precedented way to go?

[SNIPPED context: discussion of lexical scoping and closures
and why to use them instead of passing data as extra parameters
to a likelihood function]


[Rd] overhaul of mle
Ben Bolker