Default behavior for determining nobs

[stouffer]

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.

https://github.com/bbolker/bbmle/blob/918d335be65296cd5acbe82b76d694f168ca36a3/R/mle.R#L587

[bbolker]

Very late to this party, but what do you recommend in this situation?

[stouffer]

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?