Closed kirkvanacore closed 1 year ago
I suspect @jwasserman2 may be the better person to help debug this, but do you have missing data? This has been something that's come up occasionally, especially with Adam's real data, that we didn't account for properly.
There are no missing data for the variables used in this example.
There may be some blocks with 0 weights, though
On Tue, Jun 27, 2023 at 3:17 PM Kirk Vanacore @.***> wrote:
There are no missing data for the variables used in this example.
— Reply to this email directly, view it on GitHub https://github.com/benbhansen-stats/flexida/issues/131#issuecomment-1610155864, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRHA7BGHJOMBWVMODWDUBDXNM5TXANCNFSM6AAAAAAZWCP5AU . You are receiving this because you were mentioned.Message ID: @.***>
It would be great if you could share either the data. Can you, @kirkvanacore ? Or, better yet, a stripped-down, privacy preserving, data usage ageement compliant version of it that still manifests the warning?
Here is synthetic data set that produces the error:
Thanks for posting the data @kirkvanacore.ate()
is returning NA's, causing rows to be dropped. In .get_a21()
, this results in w
, which is x$weights
, to be of a shorter length than damod_mm
, which has been created by passing na.pass
to model.frame()
:
> nrow(ad[ad$R > -1 & ad$R < 11, ])
[1] 12283
> nrow(model.frame(res_BW2_1))
[1] 11930
> sum(is.na(ate(des, data = ad[ad$R > -1 & ad$R < 11, ])))
[1] 353
> 12283 - 11930
[1] 353
Thanks, all. I wonder what characterizes the blocks with NA
weights?
Blocks are numeric through 252, but only 226 exist - e.g. there is no block 41 or 42. When we expand e_z
(the block-level ratio of #treated/total num) to the observation level, we use e_z[blocks(design)[, 1]]
(R/weights.R#L132). However, if for example we're looking at block 245, e_z[245]
returns the 245rd element of a 226-length vector, NA. What we want is e_z["245"]
, to return the named entry in the vector.
Solution could be as easy as e_z[as.character(blocks(design)[,1])]
, but I don't have time right now to test it. I'll try and get to it this afternoon if no one else does.
Fix was as easy as expected. @kirkvanacore I no longer get the warning with the synthetic data; please test with your real data and let me know.
When you do get to testing this w/ the real data, @kirkvanacore, please also check whether the lmitt(<...>, absorb=T)
problem has been fixed as well. Josh E suspects that 5ffed0d4 will have taken care of it.
Hi @kirkvanacore could you check against the real data and verify that you no longer get a warning (or other sign of trouble)? If not, this issue can be closed.
@benthestatistician @josherrickson My apologies for the delay. I no longer receive the error when running lmitt(<...>, absorb=T)
against the real data.
Thanks Kirk!
@adamSales and I received a warning when requesting the summary of a limit object produced by a blocked rd design. The circumstances are detailed below:
When running this code:
...we receive this warning along with the summary: