Michael Weylandt writes:
> On Mar 19, 2014, at 22:17, Gavin Simpson wrote:
>
>> Michael,
>>
>> I think the issue is that Jeroen wants to take that responsibility out
>> of the hands of the person trying to reproduce a work. If it used R
>> 3.0.x and packages A, B and C then it would be trivial
Hadley Wickham writes:
>> What would be more useful in terms of reproducibility is the capability of
>> installing a specific version of a package from a repository using
>> install.packages(), which would require archiving older versions in a
>> coordinated fashion. I know CRAN archives old vers
Hi,
I'm having trouble building the help file for my package. One of the
parameters is a time format, and the % seems to blow things up when I do a
build.
I have tried \% \\% and as many different things as ai can think of. But
everything after the % disappears -- doesn't show up in the help
On 14-03-20 2:15 AM, Dan Tenenbaum wrote:
- Original Message -
From: "David Winsemius"
To: "Jeroen Ooms"
Cc: "r-devel"
Sent: Wednesday, March 19, 2014 11:03:32 PM
Subject: Re: [Rd] [RFC] A case for freezing CRAN
On Mar 19, 2014, at 7:45 PM, Jeroen Ooms wrote:
On Wed, Mar 19, 201
Gavin Simpson gmail.com> writes:
>
...
>
>
> To my mind it is incumbent upon those wanting reproducibility to build
> the tools to enable users to reproduce works. When you write a paper
> or release a tool, you will have tested it with a specific set of
> packages. It is relatively easy to wo
> If we could all agree on a particular set
> of cran packages to be used with a certain release of R, then it doesn't
> matter
> how the 'snapshotting' gets implemented.
This is pretty much the sticking point, though. I see no practical way of
reaching that agreement without the kind of decisi
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
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?
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 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
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 20/03/2014, at 14:14 PM, S Ellison wrote:
>> If we could all agree on a particular set
>> of cran packages to be used with a certain release of R, then it doesn't
>> matter
>> how the 'snapshotting' gets implemented.
>
> This is pretty much the sticking point, though. I see no practical way
Thanks a lot. Your correction works just fine.
Any idea of what goes wrong for the line 151, which is
int *clusterAffectation2=malloc(*nbInd * sizeof(int));
// lines 151
On 19 Mar 2014, at 22:58 , Christophe Genolini wrote:
Hi the list,
One of my package has a
On 20 Mar 2014, at 16:56 , Christophe Genolini wrote:
> Thanks a lot. Your correction works just fine.
>
> Any idea of what goes wrong for the line 151, which is
>
> int *clusterAffectation2=malloc(*nbInd * sizeof(int));
> // lines 151
>
Nothing. It's just that memche
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
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 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
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 03/20/2014 03:52 AM, Duncan Murdoch wrote:
On 14-03-20 2:15 AM, Dan Tenenbaum wrote:
- Original Message -
From: "David Winsemius"
To: "Jeroen Ooms"
Cc: "r-devel"
Sent: Wednesday, March 19, 2014 11:03:32 PM
Subject: Re: [Rd] [RFC] A case for freezing CRAN
On Mar 19, 2014, at 7:
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
On Thu, Mar 20, 2014 at 3:14 PM, Hervé Pagès wrote:
> On 03/20/2014 03:52 AM, Duncan Murdoch wrote:
>
>> On 14-03-20 2:15 AM, Dan Tenenbaum wrote:
>>
>>>
>>>
>>> - Original Message -
>>>
From: "David Winsemius"
To: "Jeroen Ooms"
Cc: "r-devel"
Sent: Wednesday, March
On Thu, Mar 20, 2014 at 1:28 PM, Ted Byers wrote:
>
> Herve Pages mentions the risk of irreproducibility across three minor
> revisions of version 1.0 of Matrix. My gut reaction would be that if the
> results are not reproducible across such minor revisions of one library,
> they are probably jus
That doesn't make sense.
If an API changes (e.g. in Matrix) and a program written against the old
API can no longer run, that is a very different issue than if the same
numbers (data) give different results. The latter is what I am guessing
you address. The former is what I believe most people a
On Thu, Mar 20, 2014 at 4:53 PM, Jeroen Ooms wrote:
> On Thu, Mar 20, 2014 at 1:28 PM, Ted Byers wrote:
>>
>> Herve Pages mentions the risk of irreproducibility across three minor
>> revisions of version 1.0 of Matrix. My gut reaction would be that if the
>> results are not reproducible across s
On Thu, Mar 20, 2014 at 5:11 PM, Tim Triche, Jr. wrote:
> That doesn't make sense.
>
> If an API changes (e.g. in Matrix) and a program written against the old
> API can no longer run, that is a very different issue than if the same
> numbers (data) give different results. The latter is what I am
> There is nothing like backups with due attention to detail.
Agreed, although given the complexity of dependencies among packages, this
might entail several GB of snapshots per paper (if not several TB for some
papers) in various cases. Anyone who is reasonably prolific then gets the
exciting pr
On Thu, Mar 20, 2014 at 5:27 PM, Tim Triche, Jr. wrote:
> > There is nothing like backups with due attention to detail.
>
> Agreed, although given the complexity of dependencies among packages, this
> might entail several GB of snapshots per paper (if not several TB for some
> papers) in various c
On 03/20/2014 01:28 PM, Ted Byers wrote:
On Thu, Mar 20, 2014 at 3:14 PM, Hervé Pagès mailto:hpa...@fhcrc.org>> wrote:
On 03/20/2014 03:52 AM, Duncan Murdoch wrote:
On 14-03-20 2:15 AM, Dan Tenenbaum wrote:
- Original Message -
From: "David
On 20.03.2014 23:23, Hervé Pagès wrote:
On 03/20/2014 01:28 PM, Ted Byers wrote:
On Thu, Mar 20, 2014 at 3:14 PM, Hervé Pagès mailto:hpa...@fhcrc.org>> wrote:
On 03/20/2014 03:52 AM, Duncan Murdoch wrote:
On 14-03-20 2:15 AM, Dan Tenenbaum wrote:
- Original M
On 03/20/2014 03:29 PM, Uwe Ligges wrote:
On 20.03.2014 23:23, Hervé Pagès wrote:
On 03/20/2014 01:28 PM, Ted Byers wrote:
On Thu, Mar 20, 2014 at 3:14 PM, Hervé Pagès mailto:hpa...@fhcrc.org>> wrote:
On 03/20/2014 03:52 AM, Duncan Murdoch wrote:
On 14-03-20 2:15 AM, Dan Tenen
Hi the list,
One of my package has an (other) error detected by memtest that I do not manage
to understand.
Here is the message that I get from Memtest
--- 8<
> try(choice(cld1))
Error in switch(EXPR = choix, Up = { : EXPR must be a length 1 vector
--- 8<
The
On 2014-03-20, 8:02 PM, Christophe Genolini wrote:
Hi the list,
One of my package has an (other) error detected by memtest that I do not manage
to understand.
Here is the message that I get from Memtest
--- 8<
> try(choice(cld1))
Error in switch(EXPR = choix, Up = { : EXPR m
Much of the discussion was about reproducibility so far. Let me emphasize
another point from Jeroen's proposal.
This is hard to measure of course, but I think I can say that the existence
and the quality of CRAN and its packages contributed immensely to the
success of R and the success of people u
> In particular, updating a package with many reverse dependencies is a
> frustrating process, for everybody. As a maintainer with ~150 reverse
> dependencies, I think not twice, but ten times if I really want to publish
> a new version on CRAN.
It might be easier if more of those packages came wi
On Thu, Mar 20, 2014 at 9:45 PM, William Dunlap wrote:
> > In particular, updating a package with many reverse dependencies is a
> > frustrating process, for everybody. As a maintainer with ~150 reverse
> > dependencies, I think not twice, but ten times if I really want to
> publish
> > a new ver
Heh, you just described BioC
--t
> On Mar 20, 2014, at 7:15 PM, Gábor Csárdi wrote:
>
> On Thu, Mar 20, 2014 at 9:45 PM, William Dunlap wrote:
>
>>> In particular, updating a package with many reverse dependencies is a
>>> frustrating process, for everybody. As a maintainer with ~150 reverse
Except that tests (as vignettes) are mandatory for BioC. So if something blows
up you hear about it right quick :-)
--t
> On Mar 20, 2014, at 7:15 PM, Gábor Csárdi wrote:
>
> On Thu, Mar 20, 2014 at 9:45 PM, William Dunlap wrote:
>
>>> In particular, updating a package with many reverse depe
- Original Message -
> From: "Gábor Csárdi"
> To: "r-devel"
> Sent: Thursday, March 20, 2014 6:23:33 PM
> Subject: Re: [Rd] [RFC] A case for freezing CRAN
>
> Much of the discussion was about reproducibility so far. Let me
> emphasize
> another point from Jeroen's proposal.
>
> This i
38 matches
Mail list logo
