[Rd] Rprofile not executed in R 2.2.0 alpha for Windows
Dear list members (esp. Duncan), I've run into the following curious problem with Version 2.2.0 alpha for Windows: Options in the Profile file in R's etc directory don't appear to be set. (I habitually uncomment options(chmhelp=TRUE), to no effect in this case.) As far as I can see, the only thing non-standard about my installation is that I put R 2.2.0 alpha under c:\R rather than under c:\Program Files. Regards, John --- Bug report info: Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = alpha major = 2 minor = 2.0 year = 2005 month = 09 day = 14 svn rev = 35574 language = R Windows XP Professional (build 2600) Service Pack 2.0 Locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, Autoloads, package:base John Fox Department of Sociology McMaster University Hamilton, Ontario Canada L8S 4M4 905-525-9140x23604 http://socserv.mcmaster.ca/jfox __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rd and guillemots
First of all, thanks to those who've set up R to work so smoothly with
Miktex-- even a total Latex bunny like me got it to work instantly, so
that for the first time I'm able to run my Rd files through the Latex
side of RCMD CHECK.
Now the question/buglet. One of my Rd files contains the following:
\code{mlazy( <>, <>, <>)}
When I run the file through RCMD (either RCMD CHECK or Rcmd Rd2dvi
--pdf) the first << and >> are left alone, but the second and third
pairs are converted to single guillemot characters (i.e. European
quotation marks). This inconsistency seems a bit odd.
Also, is there any way of getting RCMD to leave << and >> alone-- i.e.
not to guillemotize them? They cause unrecognized characters on my
(Windows XP, newly-installed Miktex, R-alpha of 10/9/2005) system when I
run the dvi files through dvips.
Thanks
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.Date() , feature or bug?
This problem was brought up by Xu Neng <[EMAIL PROTECTED]> in the rpy-list. Remember the old times when computer guys thought the year 2000 was too far away to be worried? In my case, the dates like "-06-6" and "-09-09" are used as special missing codings for dates. If R cannot handle dates later than the year 5000, it is fine. Please just let the world knows about it. What is really annoying is the fact that the default date "1970-01-01" is silently used instead of raising exception. If you are not very careful, you may not even notice this trick. This is the bug I'm referring to. Hopefully, the R experts can handle this bug seriously. Bo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] simulate in stats
I agree: no function should per default touch the random number
stream. Otherwise this will undoubtedly lead to misuse. And while one
may want to include a seed argument in case a user wants to set it
explicitly, I would argue that the preferred usage is to do
set.seed(SOMETHING)
someFunction()
and then educate users that this is the way to go.
Kasper
On Sep 15, 2005, at 9:07 AM, Paul Gilbert wrote:
> BTW, I think there is a problem with the way the argument "seed" is
> used
> in the new simulate in stats. The problem is that repeated calls to
> simulate using the default argument will introduce a new pattern into
> the RNG:
>
>
>> stats:::simulate
>>
> function (object, nsim = 1, seed = as.integer(runif(1, 0,
> .Machine$integer.max)), ...)
> UseMethod("simulate")
>
>
>
>
>> stats:::simulate.lm
>>
> function (object, nsim = 1, seed = as.integer(runif(1, 0,
> .Machine$integer.max)),...)
> {
> if (!exists(".Random.seed", envir = .GlobalEnv))
> runif(1)
> RNGstate <- .Random.seed
> set.seed(seed)
> ...
>
> This should not be done, as the resulting RNG has not been studied or
> proven. A better mechanism is to have a default argument equal NULL,
> and not touch the seed in that case. There are several examples of
> this
> in the package dse1 (in bundle dse), see for example simulate.ARMA
> and
> simulate.SS. They also use the utilities in the setRNG package to save
> more of the information necessary to reproduce simulations. Roughly it
> is done like this
> simulate.x <- function (model, rng = NULL, ...)
> {if (is.null(rng)) rng <- setRNG() #returns the RNG setting to be
> saved with the result
> else {
> old.rng <- setRNG(rng)
> on.exit(setRNG(old.rng))
> }
>...
>
>
> The seed by itself is not very useful if the purpose is to be able to
> reproduce things, and I think it would be a good idea to
> incorporate the
> few small functions setRNG into stats (especially if the simulate
> mechanism is being introduced).
>
> The argument "nsim" presumably alleviates to some extent the above
> concern about changing the RNG pattern. However, in my fairly
> extensive
> experience it is not very workable to produce all the simulations and
> then do the analysis of them. In a Monte Carlo experiment the
> generated
> data set is just too big. A better approach is to do the analysis and
> save only necessary information after each simulation. That is the
> approach, for example, in dse2:::EstEval.
>
> Paul
>
> Paul Gilbert wrote:
>
>
>> Can the arguments nsim and seed be passed as part of ... in the new
>> simulate generic in R-2.2.0alpha package stats?
>>
>> This would potentially allow me to use the stats generic rather than
>> the one I define in dse. There are contexts where nsim and seed do
>> not
>> make sense. I realize that the default arguments could be ignored,
>> but
>> it does not really make sense to introduce a new generic with that in
>> mind. (I would also prefer that the "object" argument was called
>> "model" but this is less important.)
>>
>> Paul Gilbert
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] acf() generic in R alpha
Could acf() in R-2.2.0 please be made generic? Thanks, Paul Gilbert __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] loadings() generic in R alpha
Could loadings() in R-2.2.0 please be made generic? Thanks, Paul Gilbert __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.Date() , feature or bug?
Prof Brian Ripley wrote: > > What does anyone want such dates for? I hope there was an extremely good > reason to spend other people's time on this, and look forward to an > extremely convincing explanation. > I can think of one case where I've seen exact dates that far in the future used: astronomical calculations. You may have something like "And the next chance you'll get to see Jupiter this close to Venus will be on December 12th 8766CE. Just after lunchtime in whatever remains of London then.". Is there an R package for astronomical calculations? Baz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.Date() , feature or bug?
On Wed, 14 Sep 2005, Uwe Ligges wrote: > Bo Peng wrote: > >>> Well, bug, if you really want to call it a bug that you cannot represent >>> the year . ;-) >> >> >> So I guess we need a warning message and a line in help(as.Date)? > > Even better a fix (than an *error* message), since the POSIX classes can > handle the date and I do not (yet) see the reason why Date cannot. But I > have no time to dig deeper (at least not this week). Well, actually they cannot. There is a limit of dates +/- 5000 years from the epoch (1970-01-01). This should have returned NA, and now does. What does anyone want such dates for? I hope there was an extremely good reason to spend other people's time on this, and look forward to an extremely convincing explanation. -- 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] simulate in stats
BTW, I think there is a problem with the way the argument "seed" is used
in the new simulate in stats. The problem is that repeated calls to
simulate using the default argument will introduce a new pattern into
the RNG:
> stats:::simulate
function (object, nsim = 1, seed = as.integer(runif(1, 0,
.Machine$integer.max)), ...)
UseMethod("simulate")
> stats:::simulate.lm
function (object, nsim = 1, seed = as.integer(runif(1, 0,
.Machine$integer.max)),...)
{
if (!exists(".Random.seed", envir = .GlobalEnv))
runif(1)
RNGstate <- .Random.seed
set.seed(seed)
...
This should not be done, as the resulting RNG has not been studied or
proven. A better mechanism is to have a default argument equal NULL,
and not touch the seed in that case. There are several examples of this
in the package dse1 (in bundle dse), see for example simulate.ARMA and
simulate.SS. They also use the utilities in the setRNG package to save
more of the information necessary to reproduce simulations. Roughly it
is done like this:
simulate.x <- function (model, rng = NULL, ...)
{if (is.null(rng)) rng <- setRNG() #returns the RNG setting to be
saved with the result
else {
old.rng <- setRNG(rng)
on.exit(setRNG(old.rng))
}
...
The seed by itself is not very useful if the purpose is to be able to
reproduce things, and I think it would be a good idea to incorporate the
few small functions setRNG into stats (especially if the simulate
mechanism is being introduced).
The argument "nsim" presumably alleviates to some extent the above
concern about changing the RNG pattern. However, in my fairly extensive
experience it is not very workable to produce all the simulations and
then do the analysis of them. In a Monte Carlo experiment the generated
data set is just too big. A better approach is to do the analysis and
save only necessary information after each simulation. That is the
approach, for example, in dse2:::EstEval.
Paul
Paul Gilbert wrote:
> Can the arguments nsim and seed be passed as part of ... in the new
> simulate generic in R-2.2.0alpha package stats?
>
> This would potentially allow me to use the stats generic rather than
> the one I define in dse. There are contexts where nsim and seed do not
> make sense. I realize that the default arguments could be ignored, but
> it does not really make sense to introduce a new generic with that in
> mind. (I would also prefer that the "object" argument was called
> "model" but this is less important.)
>
> Paul Gilbert
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
