I hate to ask what go this thread started but it sounds like someone was counting on exact numeric reproducibility or was there a bug in a specific release? In actual fact, the best way to determine reproducibility is run the code in a variety of packages. Alternatively, you can do everything in java and not assume that calculations commute or associate as the code is modified but it seems pointless. Sensitivity determination would seem to lead to more reprodicible results than trying to keep a specific set of code quirks.
I also seem to recall that FPU may have random lower order bits in some cases, same code/data give different results. Alsways assume FP is stochastic and plan on anlayzing the "noise." ---------------------------------------- > From: amac...@virginia.edu > Date: Mon, 4 Mar 2013 16:28:48 -0500 > To: m...@stowers.org > CC: r-devel@r-project.org; bioconduc...@r-project.org; > r-discuss...@listserv.stowers.org > Subject: Re: [Rd] [BioC] enabling reproducible research & R package > management & install.package.version & BiocLite > > On Mon, Mar 4, 2013 at 4:13 PM, Cook, Malcolm <m...@stowers.org> wrote: > > > * where do the dragons lurk > > > > webs of interconnected dynamically loaded libraries, identical versions of > R compiled with different BLAS/LAPACK options, etc. Go with the VM if you > really, truly, want this level of exact reproducibility. > > An alternative (and arguably more useful) strategy would be to cache > results of each computational step, and report when results differ upon > re-execution with identical inputs; if you cache sessionInfo along with > each result, you can identify which package(s) changed, and begin to hunt > down why the change occurred (possibly for the better); couple this with > the concept of keeping both code *and* results in version control, then you > can move forward with a (re)analysis without being crippled by out-of-date > software. > > -Aaron > > -- > Aaron J. Mackey, PhD > Assistant Professor > Center for Public Health Genomics > University of Virginia > amac...@virginia.edu > http://www.cphg.virginia.edu/mackey > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
