Should we make bias_correction argument visible

[strengejacke]

No description provided.

[DominiqueMakowski]

Can you add context

[strengejacke]

See this comment: #398 (comment)

For predictions from GLMs, we either have accurate estimates, or accurate SEs, but often not both (in your example, CIs exceed the plausible bounds).

If we add the argument bias_correction = TRUE, we have correct bounds for CIs (same we would get if we use predict = "inverse_link"), and a corrected estimate (as if we would use predict = "response").

However, the argument bias_correction, despite fully implemented, is not yet documented. It's a "user-hidden" option at the moment.

[DominiqueMakowski]

I see, thanks!

• I would say to make it default then
• For the name, I think bias_correction its fine.
• About exposing it, we could note in the details section that we implement a bias correction which might make the results slightly differ from marginaleffects, and that this can be turned off by setting the parameter. But I would say, there is no need to expose it as an argument given that the vast majority of our userbase will (probably) be happy with the default? (no strong opinion here though if we feel like the bias correction is somewhat debatable or non-consensual, happy to have it exposed too)

[strengejacke]

There's just one argument against making it the default. bias_correction required defining a sigma value, i.e. a residual standard error - which is not straightforward for mixed models. That's why this argument is also not the default in emmeans, and for mixed models, we rely on insight::get_variance() (which may slow down the computation of the bias correction). I personally would advice against making it the default, at least not now, to gain some experience how bias correction works in different settings.

[strengejacke]

We could probably add a small vignette showing the differences, based on my comment, and then see how we handle this in the future?

[DominiqueMakowski]

Fair point, yes