Check custom shared-indicator values when no difference block was fitted
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 80/100
Research direction
Start at the linked validation block in R/model_exchangeable_covariance.R around line 1764, which currently runs only when a difference block is present, and extend it to cover a fitted shared block with difference_block = NULL. The issue body contains a reproducible example using recover_exchangeable_covariance() with a shared indicator coded 0.5; run it to confirm the error now fires. Done means the example errors clearly, valid shared-only and intercept-only models still work, and the existing testthat suite for recover_exchangeable_covariance passes.
Written by the indexing model from the issue text.
Description
recover_exchangeable_covariance() translates shared and difference random effects into variances and covariances for the two dyad members.
A custom shared-indicator column must contain 1 for included rows and 0 elsewhere. The function normally checks this requirement. However, it skips the check when the model has a shared block but no difference block.
Consequently, unsupported values such as 0.5 produce plausible-looking results on the wrong scale. The function should reject this coding with a clear error.
This concerns custom columns supplied by the user. Standard columns produced by prepare_dyad_data() are unaffected.
Example
set.seed(472)
dat <- expand.grid(
member = c(-1, 1),
occasion = 1:4,
dyad = 1:50
)
dat$shared <- 0.5
shared_effect <- rnorm(50, sd = 2)
dat$y <- 2 +
dat$shared * shared_effect[dat$dyad] +
rnorm(nrow(dat), sd = 0.3)
fit <- glmmTMB::glmmTMB(
y ~ 1 + (0 + shared | dyad),
data = dat
)
recovered <- dyadMLM::recover_exchangeable_covariance(
fit,
block_pairings = list(
shared_block = "(0 + shared | dyad)",
difference_block = NULL,
shared_indicator = "shared"
)
)
c(
reported = recovered[[1]]$varcov[1, 1],
fitted_contribution =
0.5^2 * as.numeric(glmmTMB::VarCorr(fit)$cond$dyad)
)
In the checked example, the function reports 5.719249, although the selected random effect contributes 1.429812 to each member’s variance—a fourfold difference.
The model fits successfully. The problem is that covariance recovery accepts coding that its transformation does not support.
Suggested fix and checks
The current validation runs only when a difference block is present.
- Validate a named shared-indicator column whenever its shared block is fitted, including when
difference_block = NULL. - Reject values other than 0 and 1 with a clear explanation.
- Test the example above and valid shared-only models.
- Keep ordinary intercepts and valid omitted-block specifications working.
Supporting other indicator scales is outside this issue. This is separate from #29, which concerns partner positions within fitted groups.
- Dominant language
- R
- Stars
- 1
- Forks
- 2
- Avg merge
- 9h 28m
- Merged PRs (30d)
- 21
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
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Pascal-Kueng/dyadMLM#92 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Pascal-Kueng/dyadMLM#83 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 72/100
Pascal-Kueng/dyadMLM#71 · 2 comments ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 86/100
Pascal-Kueng/dyadMLM#70 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Pascal-Kueng/dyadMLM#69 ·
Maintainers usually reply within 1 day
All issues in Pascal-Kueng/dyadMLM
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
stan-dev/priorsense#150 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
xuzhougeng/wisp-science#1571 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
bennettoxford/opencodecounts#170 ·