Many thanks to Ben and Peter for their help. Even if I am not really
happy with it, I used the "environment" solution and got the results I
expected.
Issue #2 is stickier. I think I must say that the idelology of mle() is
that the user passes a likelihood function. If the likelihood function
depends on global data, and the user changes the global data, the user
deserves what he or she gets... It is pretty much impossible for mle()
to take an arbitrary function and detect which data it might depend on.
This is probably not the point, it is unreasonable to expect the
function to check if all data is there and how it is provided. If the
user wants to provide minusLogL functions that rely on global variables,
read into an Excel file or wget the data from a URL, he/she must be free
to do so, even if it does not seem to make a lot of sense. As I see it,
the problem is that there is no way for a "normal" user to provide the
data along with the likelihood function if he or she wants to. Perhaps I
am narrow-minded, but the idea I have of a canonical likelihood function
is L <- function(parameters, data) . I admit that some people, for
various reasons, may want to use alternative programming methods and
provide the data to the likelihood function in a different way, but I
can't understand why the default mle interface does not accept the
intuitive way to parameterize a likelihood function with a data=
parameter, as many other fitting procedures do (lm, glm, nls...).
Somehow, it's a pity that some users have to fork base packages because
they are not happy of their behavior, especially when adding such an
optional parameter looks quite trivial.
Thanks for the interesting discussion anyway,
Arnaud.
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
