I have come across unexpected behavior (to me) of limma's topTable function, when I am requesting confidence intervals (CIs). The CIs for many genes seem to depend on the p.value argument given to topTable. (The actual P.Value output column returned by topTable does not change, but the confidence intervals do.)

I don't know if this is the intended behavior, but it surprised me. Here is an example, based on the lmFit help page:

library(limma)

set.seed(123L)

# from lmFit help page
sd <- 0.3*sqrt(4/rchisq(100,df=4))
y <- matrix(rnorm(100*6,sd=sd),100,6)
rownames(y) <- paste("Gene",1:100)
y[1:2,4:6] <- y[1:2,4:6] + 2
design <- cbind(Grp1=1,Grp2vs1=c(0,0,0,1,1,1))
options(digits=3)
fit <- lmFit(y,design)
fit <- eBayes(fit)

Here is the output of the top 3 genes with the default p.value argument (p.value = 1):

topTable(fit, coef = 2, confint = 0.95, number = 3)  # p.value = 1 (default)

        logFC  CI.L CI.R AveExpr     t  P.Value adj.P.Val      B
Gene 2  2.104 1.616 2.59   1.070 10.15 1.67e-05   0.00167  3.620
Gene 1  2.086 1.181 2.99   1.244  5.43 9.13e-04   0.04565 -0.679
Gene 25 0.637 0.195 1.08  -0.235  3.40 1.11e-02   0.37065 -3.368

And here is the output after supplying a p.value = 0.5:

topTable(fit, coef = 2, confint = 0.95, p.value = 0.5, number = 3)

Please compare the CI.L and CI.R values for the third row, Gene 25, with that of the previous output:

        logFC  CI.L CI.R AveExpr     t  P.Value adj.P.Val      B
Gene 2  2.104  1.62 2.59   1.070 10.15 1.67e-05   0.00167  3.620
Gene 1  2.086  1.18 2.99   1.244  5.43 9.13e-04   0.04565 -0.679
Gene 25 0.637 -1.83 3.11  -0.235  3.40 1.11e-02   0.37065 -3.368

The CIs have changed (a lot), and in the second table now encompass zero - even though the reported P.Value has remained the same (and is nominally significant).

I didn't expect that the CIs would be dependent on the p.value argument. Is that the intended behavior? (If so, how are the CIs best interpreted in this context?)

Many thanks for any insights or pointers!

Session Information

R version 4.5.1 (2025-06-13)
Platform: aarch64-apple-darwin20
Running under: macOS Sequoia 15.5

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.12.1

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Los_Angeles
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base     

other attached packages:
[1] limma_3.64.1

loaded via a namespace (and not attached):
[1] compiler_4.5.1 tools_4.5.1    renv_1.1.5     statmod_1.5.0

Thanks for the reproducible example. Definitely a bug. Should not depend on p.value. The CIs with p.value=1 are correct and those with other values are not (are out of order). I will fix.

A little later: Is fixed now in limma 3.64.3 (release) and limma 3.65.3 (devel).