From marchywka at hotmail.com  Tue Mar  5 12:23:57 2013
From: marchywka at hotmail.com (Mike Marchywka)
Date: Tue, 5 Mar 2013 06:23:57 -0500
Subject: [Rd] [BioC] enabling reproducible research & R package
 management & install.package.version & BiocLite
In-Reply-To: <CAErFSogyfzMQ9UEK7e=Ukvgdg-NfxS60cPtppvvvN0MKnogyzw@mail.gmail.com>
References: <D4772401B9D976478C0895769BE3E7920716E6@MBSRV02.sgc.loc>,
	<CAErFSogyfzMQ9UEK7e=Ukvgdg-NfxS60cPtppvvvN0MKnogyzw@mail.gmail.com>
Message-ID: <BLU166-W14A5221668A7BDBAC726DEBEFB0@phx.gbl>


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
 		 	   		  


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