Add two cautions to the `simulate_dyad_responses()` help
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 70/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- r
- Domain
- documentation
Research direction
Start by locating the help entry for simulate_dyad_responses() and reading its existing cautions about dyad variance and lagged responses. Update the wording to cover zero-inflated and strongly overdispersed count models, the partner-check limitation, and the validity of model-centred summaries with lagged outcomes. Done when the help includes both cautions and the package documentation builds.
Written by the indexing model from the issue text.
Description
Two cautions from the review. I have not repeated either simulation.
The underestimated dyad variance is not limited to ordinal models. The help says glmmTMB tends to underestimate the dyad variance in ordinal models, because each dyad has only two people. The review found the same for zero-inflated Poisson models (estimated dyad SD 0.85 for a true 1.0, against 0.83 for a five-category ordinal model). A negative binomial model with strong overdispersion gave 0.91. A correct ordinal model was flagged by the partner check with 3,000 dyads, but not once in 60 runs with 500 dyads.
With a lagged outcome as predictor, raw-scale summaries flag a correct model. The help says lagged responses stay fixed. It does not say what follows. Simulations start from the observed lag with a newly drawn person effect, so raw simulated responses vary too little. In the review, the raw response SD was flagged in 30 of 30 runs with the true parameters. Model-centred summaries stayed near 5%.
Suggested fix and checks
- Widen the ordinal sentence to zero-inflated and strongly overdispersed count models, and say that the partner check is affected only with very many dyads.
- Say that with lagged outcomes only model-centred summaries are valid.
- Dominant language
- R
- Stars
- 1
- Forks
- 2
- Avg merge
- 11h 4m
- Merged PRs (30d)
- 42
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Pascal-Kueng/dyadMLM
-
documentation priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Pascal-Kueng/dyadMLM#178 ·
Maintainers usually reply within 1 day
-
Describe the brms summaries of `recover_exchangeable_covariance()` accuratelyPossibly taken A pull request linked to this issue is open or already merged. Opendocumentation good first issue priority: low
Difficulty 1/5 1-3 hours Newbie friendliness 85/100
Pascal-Kueng/dyadMLM#177 ·
Maintainers usually reply within 1 day
-
Say where `.member_contrast_*` columns may be usedPossibly taken @Voyagerroc claimed this 1 day ago. Opendocumentation good first issue priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Pascal-Kueng/dyadMLM#175 · 1 comment ·
Maintainers usually reply within 1 day
-
bug good first issue priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Pascal-Kueng/dyadMLM#173 ·
Maintainers usually reply within 1 day
-
documentation good first issue priority: low
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Pascal-Kueng/dyadMLM#171 ·
Maintainers usually reply within 1 day
All issues in Pascal-Kueng/dyadMLM
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
cran-task-views/Spatial#127 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Consider changesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
OHDSI/OmopSketch#618 ·