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 <[EMAIL PROTECTED]> 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 > http://cran.au.r-project.org/ > 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 fails. -- Brian D. Ripley, [EMAIL PROTECTED] 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
