[Rd] robustness of install.packages/update.packages (was Re: bug in L-BFGS-B? (PR#8099))

From: Berwin A Turlach <berwin_at_maths.uwa.edu.au>
Date: Sun 28 Aug 2005 - 11:16:06 GMT

G'day Brian,

I am splitting my reply to your e-mail into two since there are two separate spinoffs.

>>>>> "BDR" == Prof Brian Ripley <ripley@stats.ox.ac.uk> writes:

    BDR> Check your versions of MASS. The Windows one appears to be     BDR> an outdated version, and does different things. Thanks, yes, this is the problem. On my linux box, I compile things from source and had the latest version of MASS (7.2-19) installed under R 2.1.1 and R 2.2.0.

Since I hardly ever work under Windows, I rely for my Windows box on the precompiled versions provided from CRAN and do not compile R or packages from source. (Though I have it set up so that I can compile my own packages.) Actually, I only installed R 2.1.1 on that machine (which has an AMD processor) yesterday and it was using MASS version 7.2-16. Running `update.packages' today, updated MASS to version 7.2-18. And, lo and behold, there are no more warning messages, even more, running the example in `fitdistr' now returns:

> set.seed(123)
> x <- rgamma(100, shape = 5, rate = 0.1)
> fitdistr(x, "gamma")

     shape rate
  6.45947303 0.13593172
 (0.89052006) (0.01948648)
> ## now do this directly with more control.
> fitdistr(x, dgamma, list(shape = 1, rate = 0.1), lower = 0.01)

     shape rate
  6.48714685 0.13651706
 (0.89442924) (0.01956916)

So it was perhaps lucky that I did not run update.packages yesterday, since I would have expected that (like PR#1717) my bug report would be filed under not-reproducible. :-)

But this made me curious, and I fired my laptop (which has an Intel chip) up under Windows (usually it runs under Linux) and installed R 2.1.1 on it. On that Windows machine, I get the same answers as those reported yesterday under both MASS 7.2-16 and 7.2-18. Thus, I am a bit baffled. Well, I just went back to the AMD box and re-run the code, now it gives me again the "nonsense" answer in the second case. There is definitely something wrong in the L-BFGS-B routine, which will be hard to find.

Regarding the changed subject line:

After installing R 2.1.1 on my laptop, I executed an R source file which, essentially, only contains an install.packages command with the list of contributed packages that I like to have installed. One of this packages is DAAG and it seems that overnight the file DAAG_0.58.zip disappeared from

        http://mirror.aarnet.edu.au/pub/CRAN/bin/windows/contrib/2.1/ so the install.packages command terminated with an error message that the source file could not be downloaded.

Would it be possible to robustify the install.packages command such that it continues with installing all the other packages requested instead of terminating?

After redirecting R 2.1.1 on my laptop to use

for the CRAN repository, the install.packages() command ran without problems. I issued the command `library(MASS)' and tried out the example from fitdistr on that machine (same strange result for second command and warning messages were issued). So I said update.packages() and that command failed when it wanted to update the MASS package. So I detach()'ed MASS and re-ran update.packages() and again it failed. So I exited R 2.1.1 and restarted it again (probably I should have unloaded the namespace of MASS??) and then the update.packages command worked.

However, update.packages() wanted to update quite a few packages besides MASS (the other packages in the VR bundle, nlme, lattice &c). Once it failed on MASS, it terminated with an error and did not update any of the other packages. Would it be possible to robustify update.packages behaviour such that it would continue in such situations with updating the remaining packages?



R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sun Aug 28 21:19:47 2005

This archive was generated by hypermail 2.1.8 : Mon 20 Feb 2006 - 03:21:19 GMT