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.
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?
Cheers,
Berwin
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
