Re: [Rd] R-2.15.2 changes in computation speed. Numerical precision?

From: Spencer Graves <spencer.graves_at_structuremonitoring.com>
Date: Fri, 14 Dec 2012 10:42:52 -0800

On 12/14/2012 9:32 AM, Dirk Eddelbuettel wrote:
> On 14 December 2012 at 18:19, Uwe Ligges wrote:
> |
> |
> | On 14.12.2012 18:11, Dirk Eddelbuettel wrote:
> | >
> | > On 14 December 2012 at 18:07, Uwe Ligges wrote:
> | > | without overhead of packages. The CRAN check times of > 4000 packages
> | > | are typically a good indicator, and they are a bit slower for R-2.15.2
> |
> | Please do not quote only parts of my sentences, that one was continued:
> |
> | "but not that it is generally worrying (since we also run more checks)."
>
> I understand the resource constraint, but the fact remains that on the CRAN
> side most-visible package I am involved with now runs _way fewer_ tests than
> it used to, making these very comparisons across time a little tricky.
>
> Rock, meet hard place. In an ideal world we had way more tests, and
> comparisons among them. But time is, alas, finite...

       This raises again the question of why the CRAN resources are so constrained?

       I don't know the answer to that, but I assume it's because the current CRAN maintainers would rather force package maintainers to turn off tests than recruit help to fix the resource constraints in other ways. I just fit a log-logistic model using drm{drc} to the number of CRAN packages using data from John Fox (2009) "Aspects of the Social Organization and Trajectory of the R Project", R Journal (http://journal.r-project.org/archive/2009-2/RJournal_2009-2_Fox.pdf), with some points I added with more recent data.

       From this model fit, I estimate the doubling time for the number of CRAN packages at roughly 4.5 years. This is triple the historic 18 month speed improvements achieved since 1971 and is still 1.5 times the 3 year doubling time for number of transistors per chip forecasted by the 2010 update to the International Technology Roadmap for Semiconductors (Wikipedia, "Moore's Law"). From this, I infer that a reasonable replacement schedule for hardware in the current CRAN server farm should be able to solve this problem and release this constraint on CRAN test time.

      Jim Ramsay suggested that if money is a constraint, he has grant money that could pay some nominal fee for CRAN usage provided he could get an invoice. CRAN could still be free for anyone without the ability to easily pay such, like page charges in many journal. However, his grant money can NOT be used to make contributions.

       A "CRAN" function has been added to the "fda" package to test to see if it was running "--as-cran"; we use this to skip tests if TRUE. Ramsay and I are with Dirk: We wish there were a way to release this compute time constraint on CRAN. However, we have so far been unable to get information on the source of that constraint. (R-Forge is similarly a very valuable service with other known problems, also with unknown causes.)

       Best Wishes,
       Spencer

> Dirk
>



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Fri 14 Dec 2012 - 18:51:09 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 14 Dec 2012 - 20:13:00 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive