>>>>> Chris Chang
>>>>> on Sat, 16 May 2026 14:24:19 -0700 writes:
[............................]
>> The one-sided binom.test() does not have this kind of
>> performance problem, but the two-sided test (which can be
>> written in a manner similar to qbinom(): instead of
>> searching for minimal k satisfying pbinom(k, ...) >= p,
>> search for the innermost opposite-tail k satisfying
>> dbinom(k) <= dbinom(x)) does.
>>
>> I can submit a patch with efficient two-sided binomial
>> and Fisher's 2x2 exact test implementations if there is
>> interest.
>>
>> --Chris
Dear Chris (and other readers),
Above, you also mention binom.test(),
and indeed, when I choose numbers in the order of 1e8,
I see binom.test() taking quite some time, e.g.,
> system.time(btL <- binom.test(c(4e8, 1.01e8), p = 0.8, alternative =
> "two.sided"))
user system elapsed
8.306 0.837 9.159
and here, the time spent is really during p-value computation itself,
everything else in binom.test() being very fast, AFAICS.
Here it would be useful if you provide a patch to speed the
p-value computation, still getting exact p-values, using
pbinom() only instead of dbinom(<large_support), ..).
Traditionally, we as R core and any applied statistician would
say that in such large N cases, simple normal approximations should be accurate
enough,
which it would be practically in any case, OTOH, it would still
be nice to get the exact probabilities / confidence intervals,
with a faster calulation.
Eventually using a new argument `exact = N < 1e6` (for some N)
and using a normal (or better!) asymptotic approximation for
exact = FALSE may make sense here as well...
Thank you for raising the issue!
With best regards,
Martin
--
Martin Maechler
ETH Zurich and R Core team
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
