Zeroes not infinite weights w/ `ate()` et al
benthestatistician opened this issue · comments
In a block with 1+ treatment group members but no controls, ate() should give 0 weights to everyone. Ditto for blocks with controls but no treatments, and ditto for ett(). (Under ett() weights, treatment group members should be zero-ed out, not given weights of 1, if in blocks without controls.)
@kirkvanacore showed me an example where lmitt(<...>, weights = 'ate') produces infinite weights. It's also an example with some blocks without diversity in the treatment variable, so I'm guessing that's the issue behind his infinite weights. (This was a big data set, so we should try for a small example first.)
Addressing this seems to call for a bit of additional logic around here: https://github.com/benbhansen-stats/flexida/blob/main/R/weights.R#L103
Would it suffice to set any infinite weight to 0? Or may there be other scenarios where infinite weights are either desired, or should be set to something else?
Edit: Looking through the code more carefully, it looks like NaN weights can only occur if the ratio of num_treated_in_block/num_in_block is 1 (for both ATE & ETT) or 0 (for ATE only). So can we just always return a weight of 0 in these scenarios?
Edit 2: Including reference to your comment in the opening, it looks like in any scenario where that ratio is 0 or 1, we should zero out the weights.
Yes, I think that for any block in which num_treated_in_block/num_in_block equals 0 or 1, all weights should be zeroed out. In effect this removes from the target population any block in which we have no basis for estimating either means under treatment or means under control.
This should be addressed, @kirkvanacore feel free to let me know one way or the other.
I.e., @kirkvanacore you should now be able to execute lmitt(Z~1, <...>, weights="ate") without error, having specified blocks that are either all treatment or all control. Let us know whether that is the case?
@josherrickson this solution looks good to me. Thanks for looking into it so fast! Would you be willing to add a details block to the documentation, stating how the per-block, cluster level treatment ratios determine ate and ett weights, including the proviso about the special case treated in this issue? (The description block can come later, separate from this issue, and needn't fall to you; if you're concerned about describing the function in language capturing the intended concepts, those tasks can be left to the draftor of the description block. I'm concerned now about ensuring that the documentation capture the kind of precise info that a user would need to figure out function behavior in edge cases.)
@benthestatistician @josherrickson I am no longer receiving the error when executing lmitt(Z~1, <...>, weights="ate")