Closed krivit closed 4 years ago
Yes, this would be a consistent way to handle egor
objects with ego.design
s, when converted to stand-alone representations.
I ran the code and it works fine. With the match()
line in there it'll work also when .egoID
in ego
and alter
object are not ordered in the same manner. Seems solid to me and should also work for aaties?!
A side note on print.tbl_svy()
. For me it does not print the variables itself, but just the design info. I think I'd like it better if it would print the variables
first as a tibble
and then the design info. If I am not the only one bothered by this we could we file an issue at the srvyr
repository?!
I am thinking of implementing essentially left_join
and a full_join
methods for tbl_svy
using indexing, which we can then use in the backends. What do you think?
Actually, there's an even simpler solution: I had forgotten that we've had a workaround needed for *_join.egor
and other dplyr
verbs all along. I'll just use it here.
On even further thought, as_tibble.egor()
should always return a tibble
, and similarly with the *_df
functions. But, as_survey.egor()
should always return a tbl_svy
, as should as_alters_survey()
. This should happen regardless of whether the original egor
object has an ego design.
In particular, a user might start out with an SRS of egos (and so not specify a design), but the alter list would then be a cluster sample with their egos being the clusters. If they want that information, they can use as_alters_survey()
.
OK, I've implemented these changes. It passes the checks, and I hope this is something that makes sense in the grander project. (If not, we can always revert.)
At the moment, the design information is thrown away. Unfortunately,
srvyr
does not support joins and similar, but it does support indexing, and, also, as far as I can tell, the variables are stored separately from the design information, so it should, in principle, be possible to handle, say, alter table extraction, as follows:Any thoughts?