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

[Spencer Graves]

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
>