Search
Question: Appeal to DESeq2 authors: please keep results reproducible across version
0
gravatar for Peter Langfelder
15 months ago by
United States
Peter Langfelder1.3k wrote:

Another DESeq2 version, another change in the results. I would like to appeal to the DESeq2 authors and maintainers to please keep the results replicable across versions, at least optionally by adding arguments to the relevant functions that allow the user to choose an older way of calculating things. It would be tremendously helpful. In my case DESeq2 results are the input of multiple downstream analyses, some of which need manual intervention. Having to either re-run everything or start keeping track of multiple versions of the results gets tiring very fast.

Thanks!

ADD COMMENTlink modified 15 months ago • written 15 months ago by Peter Langfelder1.3k
1
gravatar for Steve Lianoglou
15 months ago by
Genentech
Steve Lianoglou12k wrote:

While I can't speak for the authors, I would imagine they do their best to do so, but for the benefit of the rest of us, could you comment on what changes just bit you?

ADD COMMENTlink written 15 months ago by Steve Lianoglou12k
0
gravatar for Peter Langfelder
15 months ago by
United States
Peter Langfelder1.3k wrote:

According to NEWS:

Small change to fitted mu values to improve fit stability when counts are very low. Inference for high count genes is not affected.

Indeed, the changes are small but my results (e.g., significant hits) do show some changes. I hate to whine, but when you're in a late stage of manuscript writing, with several downstream analyses, want to add one more analysis and things start changing... not a good feeling. I am re-installing R-3.2.2 so I can go back to DESeq 1.10.1 and keep things consistent.

 

 
 
ADD COMMENTlink written 15 months ago by Peter Langfelder1.3k
2

"when you're in a late stage of manuscript writing, with several downstream analyses, want to add one more analysis"

I understand where you are coming from but I have to disagree and emphasize that the solution is not to change versions of software within a project if you need the p-values to remain exactly the same. There is no way to both develop a statistical software project and deliver equal p-values across each version. The methods remain very stable across versions (I test against a battery of datasets), but there are many estimation procedures going on. It would not be possible to have every small change as an argument or else the documentation would become unreadable.

ADD REPLYlink modified 15 months ago • written 15 months ago by Michael Love14k
1

I can only second what Mike says. As you say, there are good use cases where you need exact reproducibility, but then, record the versions you used, and use these. (And Gabe Becker's switchr package might be handy for automating that.)

The change you are referring to ("Small change to fitted mu values...) seems perfectly reasonable in the evolution of this software, and overall everyone is better off with it. Who would like their new smartphone or new car be exactly backward-compatible with the previous version?

ADD REPLYlink modified 15 months ago • written 15 months ago by Wolfgang Huber13k

I see your point - but I would still suggest to make the changes less frequent, maybe collect improvements until they are substantial, then add an option to run the code the old way. Regarding keeping the R version fixed, sometimes a version change of R is forced on the user, for example when running the analysis on an organization- (e.g., school-)wide server.
 

ADD REPLYlink written 15 months ago by Peter Langfelder1.3k
1

I just have to disagree with you, because this is exactly what I have done, and the package is in fact very stable since 1.4 released in 2014. I know because I run on many test datasets and see +/- single digits of genes.

You simply can't expect the exact same set with different software versions, especially given that p-values are tail probabilities that are highly sensitive to model parameters. Changes can come from outside DESeq2 as well which would change the p-values for all genes, including annotation change, count changes, or other dependencies.

And it would be bad software design to have everything exposed to user as arguments and options.

ADD REPLYlink written 15 months ago by Michael Love14k

For the pasilla dataset, I can look at the vignette output online to see how an FDR set has changed over time. Here is a table with the number of adjusted p-values less than 0.1 for the past 4 versions of DESeq2, so going back 2 years to Fall 2014.

version LFC<0 LFC>0
1.12    392   405 
1.10    393   404 
1.8     394   409
1.6     390   408

This is what I would define as very stable, providing a fixed target for methods comparisons from other groups, while allowing minor improvements to the software and bug fixes. But if one requires the same set of genes for downstream analysis, I would not recommend changing versions.

ADD REPLYlink written 15 months ago by Michael Love14k

Managing software versions under a simple module system (environment modules) can be a great help here especially on shared research computing systems. This way you can always choose between current and historical versions whether this is R or most other software. 

ADD REPLYlink written 15 months ago by Thomas Girke1.6k
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 2.2.0
Traffic: 137 users visited in the last hour