Bug in estimateDisp of "edgeR"? "weights' matched by multiple actual arguments
2
1
Entering edit mode
Sandip Darji ▴ 30
@sandip-darji-12513
Last seen 3.5 years ago
USA/New York/Nathan Kline Institute for…

Hello, I was wondering if there is a bug in the latest "edgeR" package as I get warning message after running estimateDisp function as below.

> v <- voom(y.norm, design = design, plot = T)
> estDisp <- estimateDisp(y.norm, design, robust = T, weights = v$weights) 
Error in estimateDisp.default(y = y$counts, design = design, group = group,  :    
formal argument "weights" matched by multiple actual arguments

Then, I tried, sample specific weights despite estimateDisp function clearly stats the weights argument is the numeric matrix of observation weight

>  vq <- voomWithQualityWeights(y.norm, design = design, normalization = "none", plot = T)
>  estDisp_vqWts <- estimateDisp(y.norm, design, robust = T, weights = vq$targets$sample.weights)
Error in estimateDisp.default(y = y$counts, design = design, group = group,  :    
formal argument "weights" matched by multiple actual arguments

and got the same error.

I saw a recent reply here from Dr. Smyth that the bug has been fixed in the recent version but I thought mine would be due to a different reason.

Here is my session info and thank you very much for your time.

sessionInfo()

R version 3.6.1 (2019-07-05)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Mojave 10.14.6

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRlapack.dylib

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

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

other attached packages:
 [1] rJava_0.9-11         dplyr_0.8.3          ggrepel_0.8.1        ggplot2_3.2.1        gplots_3.0.1.1       RColorBrewer_1.1-2  
 [7] edgeR_3.26.8         Glimma_1.12.0        limma_3.40.6         BiocManager_1.30.4   XLConnect_0.2-15     XLConnectJars_0.2-15

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.2         compiler_3.6.1     pillar_1.4.2       bitops_1.0-6       tools_3.6.1        digest_0.6.21      zeallot_0.1.0     
 [8] statmod_1.4.32     jsonlite_1.6       tibble_2.1.3       gtable_0.3.0       lattice_0.20-38    pkgconfig_2.0.3    rlang_0.4.0       
[15] cli_1.1.0          rstudioapi_0.10    withr_2.1.2        vctrs_0.2.0        gtools_3.8.1       caTools_1.17.1.2   locfit_1.5-9.1    
[22] grid_3.6.1         tidyselect_0.2.5   glue_1.3.1         R6_2.4.0           fansi_0.4.0        gdata_2.18.0       purrr_0.3.2       
[29] magrittr_1.5       backports_1.1.4    scales_1.0.0       splines_3.6.1      assertthat_0.2.1   colorspace_1.4-1   labeling_0.3      
[36] utf8_1.1.4         KernSmooth_2.23-15 lazyeval_0.2.2     munsell_0.5.0      crayon_1.3.4 
edger estimateDisp • 1.6k views
ADD COMMENT
4
Entering edit mode
Aaron Lun ★ 28k
@alun
Last seen 7 hours ago
The city by the bay

You shouldn't be using voom weights in edgeR. That doesn't make sense. For example, the voom observational weights try to account for the mean-variance relationship of count data - but the NB model in edgeR already captures this relationship. So using voom weights would over-adjust for the differences in variance between low and high counts. More generally, they refer to different things - the voom weights scale the variance of the log-CPMs, while the edgeR weights scale the variance of the counts, so it doesn't make sense to use one as the other.

For completeness, I will note that the correct way to pass weights is to set y.norm$weights <- your_weights. Arguably we could have changed estimateDisp() so that it is smart enough to use weights= if it is provided and fall back to y$weights if not, but that seems like a fairly unusual use case. If you are using weights outside of recognized functions (e.g., estimateGLMRobustDisp), you had better know what you are doing.

ADD COMMENT
4
Entering edit mode
@gordon-smyth
Last seen 1 hour ago
WEHI, Melbourne, Australia

No, this isn't a bug. The estimateDisp function is behaving as documented.

estimateDisp function clearly stats the weights argument is the numeric matrix of observation weight

Please read the help page again. The help page says that weights is an argument for estimateDisp when y is count matrix but not when y is a DGEList. The help page shows two argument lists at the top of the page. The weights argument is not included for the DGEList method.

I saw a recent reply here from Dr. Smyth that the bug has been fixed in the recent version

The previous reply from me was about a different function and a different error message.

As Aaron says, you should not be trying to use weights from limma in edgeR. In fact, we do not currently recommend that users try to set their own weights at all in edgeR. We are likely to develop uses for the weights argument in the future but, for now, the weights argument is almost entirely to support the estimateGLMRobustDisp function.

ADD COMMENT

Login before adding your answer.

Traffic: 704 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6