You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm a huge fan of leveraging mle2 for fitting complex models. However, I have run into multiple instances where I obtain values for downstream quantities like AICc which don't make sense.
Approximately 99 times out of 100, this is because the value being determined internally for nobs is incorrect. Because the object passed to the function using the argument data could hypothetically take just about any form, it seems to me that the assumption inherent in the following line of code is only sometimes guaranteed to be correct.
My turn to be excessively belated. Not sure how I missed this!
Off the top of my head, I would say that the only time when nobs can confidently be determined internally is when the user passes a formula and not a function as the first argument.
In any other case, the code is beholden to a user knowing that their first item in data must be of appropriate length when it could just as easily be a scalar, character, or anything else under the sun. Therefore it would seem like, when the first argument is a function, the safest route is for the user to be forced to include nobs either as a named object within data (which feels weird, since data in theory is just information need to calculate the nll) or as an additional argument to mle2() itself.
Or maybe just the line in question gets amended to include a warning telling the user what has to date been happening silently within the code?
I'm a huge fan of leveraging
mle2
for fitting complex models. However, I have run into multiple instances where I obtain values for downstream quantities like AICc which don't make sense.Approximately 99 times out of 100, this is because the value being determined internally for
nobs
is incorrect. Because the object passed to the function using the argumentdata
could hypothetically take just about any form, it seems to me that the assumption inherent in the following line of code is only sometimes guaranteed to be correct.bbmle/R/mle.R
Line 587 in 918d335
The text was updated successfully, but these errors were encountered: