On Thu, 20 Mar 2014, Dirk Eddelbuettel wrote:
o Roger correctly notes that R scripts and packages are just one issue.
Compilers, libraries and the OS matter. To me, the natural approach these
days would be to think of something based on Docker or Vagrant or (if you
must, VirtualBox). The
On 21 March 2014 at 07:43, Therneau, Terry M., Ph.D. wrote:
| This has been a fascinating discussion.
I am not so sure. Seems more like rehashing of old and known arguments, while
some folks try to push their work (Hi Jeroen :) onto already overloaded
others. The only real thing I learned so far
On Fri, Mar 21, 2014 at 8:43 AM, Therneau, Terry M., Ph.D. <
thern...@mayo.edu> wrote:
[...]
>
> Gabor Csardi discussed the problems with maintaining a package with lots
> of dependencies.
> I maintain the survival package which currently has 246 reverse
> dependencies and take a slightly different
This has been a fascinating discussion.
Carl Boettinger replied with a set of examples where the world is much more fragile than
my examples. That was useful. It seems that people in my area (medical research and
survival) are more careful with their packages (whew!).
Gabor Csardi discussed
On Mar 20, 2014, at 1:02 PM, Marc Schwartz wrote:
>
> On Mar 20, 2014, at 12:23 PM, Greg Snow <538...@gmail.com> wrote:
>
>> On Thu, Mar 20, 2014 at 7:32 AM, Dirk Eddelbuettel wrote:
>> [snip]
>>
>>>(and some readers
>>> may recall the infamous Pentium bug of two decades ago).
>>
>> It
Given the version / dated snapshots of CRAN, and an agreement that
reproducibility is the responsibility of the study author, the author
simply needs to sync all their packages to a chosen date, run the analysis
and publish the chosen date. It is true that this doesn't include
compilers, OS, syste
On Mar 20, 2014, at 12:23 PM, Greg Snow <538...@gmail.com> wrote:
> On Thu, Mar 20, 2014 at 7:32 AM, Dirk Eddelbuettel wrote:
> [snip]
>
>> (and some readers
>> may recall the infamous Pentium bug of two decades ago).
>
> It was a "Flaw" not a "Bug". At least I remember the Intel people
There seems to be some question of how frequently changes to software
packages result in irreproducible results.
I am sure Terry is correct that research using functions like `glm` and
other functions that are shipped with base R are quite reliable; and after
all they already benefit from being ve
On Thu, Mar 20, 2014 at 7:32 AM, Dirk Eddelbuettel wrote:
[snip]
> (and some readers
>may recall the infamous Pentium bug of two decades ago).
It was a "Flaw" not a "Bug". At least I remember the Intel people
making a big deal about that distinction.
But I do remember the time well, I
No attempt to summarize the thread, but a few highlighted points:
o Karl's suggestion of versioned / dated access to the repo by adding a
layer to webaccess is (as usual) nice. It works on the 'supply' side. But
Jeroen's problem is on the demand side. Even when we know that an
analysi
On 3/20/2014 9:00 AM, Therneau, Terry M., Ph.D. wrote:
On 03/20/2014 07:48 AM, Michael Weylandt wrote:
On Mar 20, 2014, at 8:19, "Therneau, Terry M., Ph.D."
wrote:
There is a central assertion to this argument that I don't follow:
At the end of the day most published results obtained wit
On 03/20/2014 07:48 AM, Michael Weylandt wrote:
On Mar 20, 2014, at 8:19, "Therneau, Terry M., Ph.D." wrote:
There is a central assertion to this argument that I don't follow:
At the end of the day most published results obtained with R just won't be
reproducible.
This is a very strong
On Mar 20, 2014, at 8:19, "Therneau, Terry M., Ph.D." wrote:
> There is a central assertion to this argument that I don't follow:
>
>> At the end of the day most published results obtained with R just won't be
>> reproducible.
>
> This is a very strong assertion. What is the evidence for it?
There is a central assertion to this argument that I don't follow:
At the end of the day most published results obtained with R just won't be
reproducible.
This is a very strong assertion. What is the evidence for it?
I write a lot of Sweave/knitr in house as a way of documenting complex an
14 matches
Mail list logo
