Why sum technical replicates instead of averaging (and rounding) for DESeq?
It is widely recommended to sum technical replicate samples for differential gene expression analysis.
I was wondering why this is the case, and not averaging the technical replicates into a single value for the individual? 
I suppose that summing would give greater statistical power. If you have 10 replicates, each with 1 read mapped to some gene, then the sum would be 10 and the average 1. 1 event is a lot more likely to be noise than 10 events.
Aside from that, averaging and rounding would lose precision for no gain. 
I just ended up asking a very similar question looking for guidance. When you say 'widely recommended' can you provided a paper or technical reference that says this? That would help me greatly.

There is a theoretical justification. The sum of Poisson RVs (random variables) is Poisson. Raw counts of uniquely assigned reads to genes are very close to Poisson distribution across technical replicates. And the statistical model includes Poisson RVs or RVs with higher dispersion (due to biological variation). So the sum is a good idea for summarizing technical replicates.
Note that the average of Poissons is not Poisson, for example, it has less variance than the mean. Suppose we take the mean of 5 Poisson RVs with lambda=10 and call this new thing X. The expected value will be 10, > mean(replicate(1000, mean(rpois(5, lambda=10)))) [1] 9.9804 but the variance of X is now less than the mean: > var(replicate(1000, mean(rpois(5, lambda=10)))) [1] 1.951687 This kind of a RV, a count which is underdispersed, is not possible to model with the countbased methods. 
Sorry to dig up the old post, I think my question is relevant to this discussion.
From practical point of view, technical replicates from the same RNA sample can be merged together into a single fastq file for mapping and subsequent counting. Is this the correct approach? Alternatively, should mapping be done separately and counts added subsequently? Tophat is my current mapper, but please commend on whether this works with other mappers. Thanks 
It doesn't really matter if you map and merge or merge and then map, you'll get essentially the same results regardless. This is true regardless of the aligner.

All times are GMT 8. The time now is 04:14 AM. 
Powered by vBulletin® Version 3.8.9
Copyright ©2000  2019, vBulletin Solutions, Inc.