Dear list, I got the biological coefficient of variation (BCV) with edgeR by calcualting sqrt(tagwisedisp). I'd would like to compare it with the BCV given by DeSeq. However I am not sure what variable in DeSeq gives me the equivalent value for comparison. Should I use the sqrt(perGeneDispEsts) or the sqrt(fittedDispEsts) function provided by the fitInfo function?... or maybe none of them? My naive expectation is that I should obtain with DeSeq very similar BCV values for each gene to those obtained with edgeR, right? Many thanks! Miguel Gallach [[alternative HTML version deleted]]

Hi Miguel On 04/12/2012 05:23 PM, Miguel Gallach wrote: > I got the biological coefficient of variation (BCV) with edgeR by > calcualting sqrt(tagwisedisp). > I'd would like to compare it with the BCV given by DeSeq. However I am not > sure what variable in DeSeq gives me the equivalent value for comparison. > Should I use the sqrt(perGeneDispEsts) or the sqrt(fittedDispEsts) function > provided by the fitInfo function?... or maybe none of them? > > My naive expectation is that I should obtain with DeSeq very similar BCV > values for each gene to those obtained with edgeR, right? I would expect that the tagwise dispersion value provided by edgeR is typically somewhere in between DESeq's fitted dispersion estimate and the per-gene dispersion estimate. Early versions of DESeq only used the fitted dispersion value, which was unsatisfactory because it made DESeq rather vulnerable to outliers. This is why we now perform the quite conservative approach of using the maximum of these to values. See this post for details: https://stat.ethz.ch/pipermail/bioconductor/2011-December/042441.html EdgeR instead uses shrinkage estimation to find a compromise between these extremes. In principle, this is preferable to our more naive approach as it offers more power, and you may wonder why DESeq does not use something similar. The reason is that we feel that edgeR's specific shrinkage estimator does not offer the robustness we consider required (at least in our simulation) and hence opted for DESeq's current simple but safe approach, while we are thinking about something better. The bottom line is: The true value is somewhere between the two values that DESeq gives you. EdgeR attempts to find this middle ground, DESeq does not, and the reason for this difference is that the edgeR authors and we disagree on whether existing schemes to do so are reliable for the kind of data that users may apply them to in practice. As you are already comparing both tools, you will probably form your own opinion. Simon