similar to: R-devel Digest, Vol 143, Issue 25

I am doing [R version 3.1.2 (2014-10-31) -- "Pumpkin Helmet?; Platform: x86_64-apple-darwin10.8.0 (64-bit)] > R CMD build DAAGviz > R CMD check DAAGviz_1.0.3.tar.gz Without a .Rinstignore file, I get: <<< The following files should probably not be installed: ?figs10.pdf?, ?figs11.pdf?, ?figs12.pdf?, ?figs13.pdf?, ?figs14.pdf?, ?figs5.pdf?, ?figs6.pdf?, ?figs9.pdf?

Sorry. This, and the description in the ?Writing R Extensions? manual, leaves me completely mystified. Is it that I have to remove the PDFs that are created when I run ?R CMD build?, and somehow ensure that they are rebuilt when the package is installed? Do I need a Makefile? John Maindonald email: john.maindonald at anu.edu.au<mailto:john.maindonald at anu.edu.au> phone :

I a few of my packages I'd like to be able to add files starting with a period that installs with the package, e.g. inst/configs/.BatchJobs.R. Currently [R Under development (unstable) (2013-09-08 r63880)], R CMD check --as-cran complaints about this as: * checking for hidden files and directories ... NOTE Found the following hidden files and directories: inst/configs/.BatchJobs.R These

Hello. R-devel, r61697. I am having difficulty interpreting section 1.4 "Writing package vignettes" of the R-exts manual. Specifically, I want to use system.file() in some of my packages to locate a bib file, uncertainty.bib, which is part of the emulator package. I only want to maintain a single .bib file. R-exts says: "All other files needed to re-make the vignette PDFs (such

The build system has rolled up R-2.15.2.tar.gz (codename "Trick or Treat") at 9:00 this morning. This is a maintenance release; see the list below for details. You can get it from http://cran.r-project.org/src/base/R-2/R-2.15.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team Peter

The build system has rolled up R-2.15.2.tar.gz (codename "Trick or Treat") at 9:00 this morning. This is a maintenance release; see the list below for details. You can get it from http://cran.r-project.org/src/base/R-2/R-2.15.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team Peter

The build system has rolled up R-2.15.2.tar.gz (codename "Trick or Treat") at 9:00 this morning. This is a maintenance release; see the list below for details. You can get it from http://cran.r-project.org/src/base/R-2/R-2.15.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team Peter

You've omitted a comma. races2000 is a data frame, which for purposes of extracting rows behaves like a 2-dimenional object. The following works fine: hills2000 <- races2000[races2000$type == 'hill', ] Additionally, you might like to ponder > type <- races2000[names(races2000)=="type"] > type[1:4] Error in "[.data.frame"(type, 1:4) :

<soap-box> While I agree with John about abuse of methodology, I can't subscribe to the "failure to read the manual" proposition. I don't mean to lecture, but it would seem to me that people who, like me, will probably gain far more from this list than we will be able to contribute (at least in the near term) owe it to those who will likely contribute far more than they

I have posted, at http://wwwmaths.anu.edu.au/~john/r/newsets/ image (.rda) files, and first stabs at .Rd files for various data on deaths in London from 1629 to 1939. (There are of course gaps.) The sources (Guy 1882 & Stocks 1942) are documented in the .Rd files: (1) poxetc: measles, smallpox & total deaths: 1629-1881 [I have deliberately left several inconsistencies that were in

Hi Ross - I believe I was wrong in thinking that passing via the ... list to stripchart() was ever allowed. Here are patches: Add ... to the argument list Add, at the beginning of the function: pars <- list(...) There are two calls to axis(). Modify these to: axis(1, at = at, labels = names(groups), las=pars$las) axis(2, at = at, labels = names(groups), las=pars$las) Also

Finding and not unnecessarily duplicating existing functionality is important also from a user perspective. Negative binomial regression provides a somewhat extreme example of existing overlap between packages, with the scope that this creates for confusing users, especially as the notation is not consistent between these different implementations. In addition to MASS::glm.nb(), note

With lme4, use of mcmcsamp can be insightful. (Douglas Bates drew my attention to this function in a private exchange of emails.) The distributions of random effects are simulated on a log scale, where the distributions are much closer to symmetry than on the scale of the random effects themselves. As far as I can see, this is a straightforward use of MCMC to estimate model parameters; it is not

I'd use mcmcsamp() to examine the posterior distribution, under a relatively uninformative prior, of of the parameter estimates. For estimates that are based on four or five or more "degrees of freedom", I'd surmise that the prior will not matter too much. With estimates where the number of "degrees of freedom" is one or two or three, the posterior distribution may vary

Typing in statements from the command line transfers to the computer a macro that was perhaps in the user's head. Putting together small sequences of carefully thought out code, in which key components have been carefully thought out and tested, has to be, for most of us, better than trying to make it all up on the run. An exception is necessary for those unusual people who who (akin to the

# r-bugs@r-project.org The problem occurs when the model matrix has a single column. > elastic <- data.frame(stretch=c(46,54,48,50,44,42,52), distance=c(183,217,189,208,178,150,249)) > elastic.lm <- lm(distance ~ -1 + stretch, data=elastic) > predict(elastic.lm,se=T) Error in XRinv^2 %*% rep(res.var, p) : non-conformable arguments The fix is to replace XRinv <-

The following failed to make it to r-help when Murray Jorgensen sent his message a little time ago. [It seems to have been an issue of the machine from which my message originated.] Typing in statements from the command line transfers to the computer a macro that was perhaps in the user's head. Putting together small sequences of carefully thought out code, in which key components have been

The message for aov1 was "Estimated effects <may> be unbalanced". The effects are not unbalanced. The design is 'orthogonal'. The problem is that there are not enough degrees of freedom to estimate all those error terms. If you change the model to: aov1 <- aov(RT~fact1*fact2*fact3+Error(sub/(fact1+fact2+fact3)),data=myData) or to aov2 <-

There are answers that could and should be applied in specific situations. At least in academia and in substantial research teams, statisticians ought to have a prominent part in many of the research teams. Senior statisticians should have a prominent role in deciding the teams to which this applies. why should it be ok to do combine high levels of chemical expertise with truly appalling

It really is unclear what is claimed to be a bug here. But see https://stat.ethz.ch/pipermail/r-devel/2007-May/045592.html for why the bug is not in R: your old and new data do not match. Your fit is to a category. [The problem with the web interface to R-bugs was reported last week: it is being worked on.] On Mon, 30 Apr 2007, r.darnell at uq.edu.au wrote: > This is a multi-part