Closed junder873 closed 1 year ago
One additional change I considered but did not implement is that the biascorrection tests often need the y and/or mu values, expecting these to be in the augment_df argument. Saving them all the time in order to calculate pseudo-r2 might make it unnecessary to keep those in the augment_df
Thanks. There are two disadvantages that I see: (1) we store much more data in the estimated model (I'd prefer them to be as light as necessary, in contrast to e.g. stargazer etc); (2) we need to specify the type (you coded y
and mu
as Vector{Float64}
, whereas with lower-end GPUs you may prefer Float32
s). So I'd suggest that we return those statistics only if the necessary information has been saved in augmentdf
.
As an alternative (that I think alleviates both of those), what if loglikelihood and nullloglikelihood were calculated within nlreg and then saved (similar to deviance and nulldeviance)? This would have a pretty minimal effect on speed and mean very little additional information is stored. Thoughts?
Agreed, I think that would be a good solution.
Patch coverage: 100.00
% and project coverage change: +0.34
:tada:
Comparison is base (
ee22701
) 90.89% compared to head (7032b28
) 91.24%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
This adds support for calculating pseudo-r2 values. To do so, functions for loglikelihood and nullloglikelihood are added and the output type needs to store a few extra variables (y, mu and a dof).
One additional change I considered but did not implement is that the biascorrection tests often need the y and/or mu values, expecting these to be in the augment_df argument. Saving them all the time in order to calculate pseudo-r2 might make it unnecessary to keep those in the augment_df