[Rd] robustness of install.packages/update.packages (was Re: bug in L-BFGS-B? (PR#8099))
Prof Brian Ripley
ripley at stats.ox.ac.uk
Sun Aug 28 19:17:20 CEST 2005
We've never encountered this lying mirror problem. Perhaps you (or
another user of the unreliable mirror) could contribute suitable fixes.
On Sun, 28 Aug 2005, Berwin A Turlach wrote:
> 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 at 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:
>> 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
> 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.
Yes, and that *is* in the rw-FAQ.
> 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?
Not a good idea. Better to follow the FAQ. At that point the dependencies
have been worked out and will not be re-computed if a package installation
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-devel