Question regarding lib.sizes when using glmQLFit
1
0
Entering edit mode
@steve-pederson-3490
Last seen 2.6 years ago
Australia

When using the Quasi-Likelihood dispersions via glmQLFit in edgeR, and providing a DGEList as input, the function glmQLFit.DGEList() explicitly passes the value lib.size = NULL to the lower-level function glmQLFit(). This forces the library sizes to be the column sums when passed eventually to the lower-level function .compressOffsets(). I'm really struggling to see the justification for this.

My situation is that I'm using sliding windows via the workflow presented at https://f1000research.com/articles/4-1080/v2 and as such, the library size is not the sum of the reads in each column. I would like to use the correct library sizes I have assigned to the lib.size element of my DGEList. Clearly, I can just write my own function to get around this. However, is this an intentional decision with solid reasoning that's beyond me, or just one that slipped through?

glmQLFit edgeR • 1.1k views
ADD COMMENT
1
Entering edit mode
Yunshun Chen ▴ 890
@yunshun-chen-5451
Last seen 1 day ago
Australia

glmQLFit.DGEList() not only passes lib.size=NULL but also passes an offset obtained by getOffset() to the low-level function glmQLFit(). In your case, this offset would be computed using the corrected lib.size stored in your DGEList object. And offset always takes precedence over lib.size in the low-level function glmQLFit().

ADD COMMENT
0
Entering edit mode

Thanks Andy. That makes sense for sure.

ADD REPLY
0
Entering edit mode

The precedence of offset over lib.size is documented on the glmQLFit help page.

ADD REPLY

Login before adding your answer.

Traffic: 557 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