Accounting for "ties" in rank-biserial corr in paired/one-sample cases
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start at the .r_rbs implementation used by rank_biserial() for paired or one-sample inputs, and reproduce the report with the sleep data and mu = 0. Compare the current result with the proposed tie handling and establish regression coverage showing that the tied comparison is not treated as a perfect effect.
Written by the indexing model from the issue text.
Description
For paired samples (or one-sample), the rank-biserial correlation gives a (seemingly) odd result when there are ties with the mu argument. For example (code below), if I use the sleep data set there will be 1 tie between the paired comparisons therefore, in my opinion, the effect size, or probability of superiority, should not be -1.00 or 0%. Is there any particular reason for this?
> # example of function
> rank_biserial(extra ~ group, data = sleep, paired = TRUE,
+ parametric = FALSE, mu = 0)
r (rank biserial) | 95% CI
----------------------------------
-1.00 | [-1.00, -1.00]
> # take paired differences
> z = subset(sleep, group == 1)$extra - subset(sleep, group == 2)$extra
> # calculate sum less than zero
> # not equal to 100% less!
> sum(z < 0) / length(z)
[1] 0.9
My feeling is that with .r_rbs should actually be the following for paired samples.
z = na.omit((x - y) - mu)
Ry <- effectsize:::.safe_ranktransform(z, sign = TRUE, verbose = verbose)
Ry0 <-ifelse(is.na(Ry),1,0)
Ry <- stats::na.omit(Ry)
n <- length(na.omit((x - y) - mu))
S <- (n * (n + 1) / 2)
U1 <- sum(Ry[Ry > 0], na.rm = TRUE) + 0.5*sum(Ry0[Ry0 == 1], na.rm = TRUE)
U2 <- -sum(Ry[Ry < 0], na.rm = TRUE) + -0.5*sum(Ry0[Ry0 == 1], na.rm = TRUE)
u_ <- U1 / S
f_ <- U2 / S
u_ - f_
For this exact example, it provides the correct result (again, just my opinion).
- Dominant language
- R
- Stars
- 353
- Forks
- 25
- Avg merge
- 9h 21m
- Merged PRs (30d)
- 1
Contributor 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 easystats/effectsize
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
easystats/effectsize#709 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
easystats/effectsize#708 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 20/100
easystats/effectsize#705 · 1 comment ·
-
consistency :apple: :green_apple: docs 📑
Difficulty 3/5 1-2 days Newbie friendliness 35/100
easystats/effectsize#681 · 1 comment ·
-
Significance tests Openenhancement 🔥
Difficulty 5/5 Over a week Newbie friendliness 25/100
easystats/effectsize#638 · 7 comments ·
All issues in easystats/effectsize
Similar issues
-
documentation pkg infrastructure
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
epiverse-trace/epiparameter#511 ·
-
function:write_dwc
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
r-lib/pkgdepends#485 · 3 comments ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
beginners blocker
Difficulty 2/5 1-3 hours Newbie friendliness 78/100