[Rd] [BioC] enabling reproducible research & R package management & install.package.version & BiocLite

Mike Marchywka marchywka at hotmail.com
Tue Mar 5 12:23:57 CET 2013


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: amackey at virginia.edu
> Date: Mon, 4 Mar 2013 16:28:48 -0500
> To: MEC at stowers.org
> CC: r-devel at r-project.org; bioconductor at r-project.org; r-discussion at 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 <MEC at 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
> amackey at virginia.edu
> http://www.cphg.virginia.edu/mackey
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
 		 	   		  


More information about the R-devel mailing list