make `type=` argument to `vcovDA` more flexible
josherrickson opened this issue · comments
As it stands right now, if someone wanted to add a new "type" to vcovDA, they'd need to manually add an entry to the switch statement: https://github.com/benbhansen-stats/flexida/blob/1f9ca1c0dbe6e2b0adcf493210cbe6662f500ec1/R/SandwichLayerVariance.R#L21-L26
I'd like to make this more flexible. My first idea is to define some function template, say .vcovDA_, and call something like vcovfunc <- eval(paste0(".vcovDA_", type)). We could also be tricky and allow users to pass their own functions, requiring a standard input and output. @jwasserman2 happy to take the lead in implementing this, just wanted to bring it up for discussion in case any has objections or a better suggested interface.
This is an interesting thought, but one of the reasons people would use our package in the first place is that we've already written up complex variance estimation functions. It's not apparent to me why they would want to input their own function, unless you have an example where that might be of interest
One scenario where the functionality @josherrickson would be proposing is helpful is if/when someone came asking us to implement their favorite flavor. Rather than trying to figure out a polite way to tell them we don't have time, we could let them have at it themselves. This may or may not be part of what Josh E has in mind. I myself am for whatever, provided we all bear the KISS principle in mind.
Exactly as @benthestatistician says. I'm working on adding a new method myself so it'll require modifying that code chunk anyways, so no big deal to update the whole thing.
@benthestatistician I understand the benefit you've pointed out, but I don't see the scenario that anyone in the near future would write a variance function that takes advantage of our internal machinery. Furthermore, we've set it up as is because we wanted to allow people to easily specify strings that link to internal functions. This seems to be going against the way we originally envisioned this as well as going against the sandwich package setup.
@josherrickson Why would your new method require changing what we already have? Can you explain that before you start making changes? Feel free to message me offline
No, no change to vcovDA's arguments. It'd just be replacing
var_func <- switch(
type,
"CR0" = .vcovMB_CR0,
"MB0" = .vcovMB_CR0,
"HC0" = .vcovMB_CR0
) with something like
var_func <- get(paste0(".vcovMB_", type))probably with some tryCatch in case the user passes in a type for which a .vcovMB_ doesn't exist. (By the way, can you remind me what MB stands for? Do we want to stick with .vcovMB_* instead of .vcovDA_ or just .vcov_?)
We'd also have .vcovMB_MB0 <- .vcovMB _HC0 <- .vcovMB_CRO.
Thanks for explaining; what you're proposing is different than how I had it in my mind. We can use match.arg() functionality to ensure users provide a valid type argument, then do what you've proposed above.
MB stands for "model-based". Xinhe is writing a .vcovDB_CR0 function, DB meaning "design-based".
If a user requests type = CR0, what distinguishes whether they're looking for .vcovMB_CR0 or .vcovDB_CR0? I see in Xinhe's branch DR0: https://github.com/benbhansen-stats/flexida/blob/b1a41083696b008a1abdee052ccffab67867878d/R/SandwichLayerVariance.R#L26
Is that the plan? Should we instead have two arguments, type= and basis= or something? Or is DB0 a general enough term? Can we drop the DB/MB and just have .vcov_CR0 and .vcov_DB0?
I agree w/ @josherrickson that it would be best to have vcovDA(type=) specifications involving the string "CR0" resolve to a single method unambiguously. I think we should be able to do this without adding a new argument. In particular, I think it should be fine for the "DB_CR0" type to become just "DR0", as in @xinhew0708's design branch. Or perhaps something similar, but without the "CR0". (With apologies for belated post.)
So we'll have:
"CR0"corresponding to.vcov_CR0"MB0"corresponding to.vcov_MB0"HC0"corresponding to.vcov_HC0"DR0"corresponding to.vcov_DR0
Then we'd also add
.vcov_MB0 <- .vcov _HC0 <- .vcov_CR0
as synonyms. Users (or us) could define our own method by simply creating a .vcov_XXX functions. This drops the DB_ or MB_ entirely; we can simply document which corresponds to which.
Any objections?
Friendly amendment: "DB0", not "DR0". Ok?
I've made this change. @xinhew0708 you can name your function .vcov_DB0 per Ben's last comment whenever you get a chance.
Oh, also, I started some very preliminary documentation of these choices:
propertee/R/SandwichLayerVariance.R
Lines 5 to 8 in 00da109