get_varcov: default to CR2 if HC3 isn't available for a model

[bwiernik]

trafficstars

1. Currently, if robust = TRUE, we default to sandwich::vcovHC(..., type = "HC3"). This works great for many models, but some models, like "merMod", only have sandwich estimators in clubSandwich::vcovCR(). By default, if a model doesn't have a vcovHC() method, we should check for a vcovCR() method and default to "CR2".

2. If someone requests "HC" for an unsupported model, we should suggest they try "CR" instead.

3. If someone requests "CR" but doesn't give a type in vcov_args, we should automatically add "CR3" as the type.

[vincentarelbundock]

I agree we should improve things in that area. A few thoughts:

1. I don't think we should automatically go from HC to CR as those are different things, statistically speaking. If the user explicitly requests HC, we should either give them HC or fail with an informative message if we can't. (Warnings or messages are often missed, so failure seems best to me.)
2. See above.
3. Absolutely. Setting and documenting a default value seems sensible.

[bwiernik]

Regarding (1), I'm referring to the default we define when all the user gives is robust = TRUE. Currently we default to HC, but that's not available for mixed effects models. CR is a good option for default for mixed models.

For (2), I'm fine with an error. The error should direct them toward CR.

[vincentarelbundock]

Right.

I just thought the spirit was to deprecate robust, because it is a confusing labelled used in a ton of different ways. Instead, the vcov refactor was meant to steer people away from the robust argument, toward explicit specification of the type of robustness they hope for. In that context, the relevant comparison between two "defaults" for different models. For both traditional and mixed-models, the default errors are the usual IIDs (with vcov=NULL). To me, at least, it feels confusing --and strictly incorrect-- for a user to explicitly set vcov="HC" but get something different.

[strengejacke]

3. is resolved.

[strengejacke]

Since we want to deprecate robust, I think 1. and 2. are obsolete now?

[vincentarelbundock]

yes, obsolete, I think