On Dec 7, 2007 8:43 AM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > 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
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. > >> (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 > >> > >> > > > > > > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel