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

[Antonio, Fabio Di Narzo]

2007/12/7, Ben Bolker <bolker at ufl.edu>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Luke Tierney wrote:
> > On Fri, 7 Dec 2007, Duncan Murdoch wrote:
> >
> >
> >
> > For working at the general likelihood I think is is better to
> > encourage the approach of definign likelihood constructor functions.
> > The problem with using f, data is that you need to mathc the names
> > used in f and in data, so either you have to explicitly write out f
> > with the names you have in data or you have to modify data to use the
> > names f likes -- in the running example think
> >
> >     f <- function(lambda) -sum(dpois(x, lambda, log=T))
> >     d <- data.frame(y=rpois(10000, 12.34))
> >
> > somebody has to connext up the x in f with the y in d. With a negative
> > log likelihood constructor defines, for example, as
> >
> >     makePoisonNegLogLikelihood <- function(x)
> >         function(lambda) -sum(dpois(x, lambda, log=T))
> >
> > this happens naturally with
> >
> >     makePoisonNegLogLikelihood(d$y)
> >
> >
>
>   I hate to sound like a jerk, but I do hope that in the end we come
> up with a solution that will still be accessible to people who don't
> quite have the concept of writing functions to produce functions.  I
> feel it is "natural" for people who have multiple data sets to have the
> variables named similarly in different data sets.  All of the
> constructor stuff is still accessible to anyone who wants to use the
> function that way ... is there any way to do a cheesy default
> constructor that is just equivalent to taking the likelihood function
> and arranging for it to be evaluated in an environment containing
> the data?  That way if "nllmaker" below were just a formula
> or a log-likelihood function it could still work ...

I don't really agree with this.
I found really natural writing functions which builds other functions,
for handling
in a clean way the data-dependency problem, much more than
manipilating function environments.
As a useR, I think that if I'm able to write a likelihood function myself:

data <- whatever
negloglik <- function(theta)
  a + very * complicated / function - of %% theta %*% and %o% data

to be used in mle, I'm also good at abstracting it a bit this way:

nllmaker <- function(data)
  function(theta)
    a + very * complicated / function - of %% theta %*% and %o% data

negloglik <- nllmaker(whatever),

don't you think? I use this kind of tricks routinely for simulations.
In general, I think it should be more emphatized functional style in R coding.
In fact, I like a lot the recent introduction of some higher order
functions in the base package (Reduce, Filter, Map).

Bests,
Antonio, Fabio.
>
>   [snip]
> > Both (simple) bootstrapping and (simple leave-one-out) crossvalidation
> > require a data structure with a notion of cases, which is much more
> > restrictive than the conext in which mle can be used.  A more ngeneric
> > aproach to bootstrapping that might fit closer to the level of
> > generality of mle might be parameterized in terms of a negative log
> > likelihood constructor, a starting value constructor, and a resampling
> > function, with a single iteration implemented soemthing like
> >
> >     mleboot1 <- function(nllmaker, start, esample)  {
> >     newdata <- resample()
> >     newstart <- do.call(start, newdata)
> >     nllfun <- do.call(nllmaker, newdata)
> >     mle(fnllfun, start = newstart)
> >     }
> >
> > This would leave decisions on the resampling method and data structure
> > up to the user. Somehing similar could be done with K-fold CV.
> >
> > luke
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHWcS1c5UpGjwzenMRAig2AJ9iTzhI1p8tBb7Q15jgT4nA+Zds+gCgggc2
> sI2que28Hl1M5cVGa+anEL0=
> =hCiS
> -----END PGP SIGNATURE-----
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Antonio, Fabio Di Narzo
Ph.D. student at
Department of Statistical Sciences
University of Bologna, Italy