Sociologist. Quantitativist. University of Neuchâtel.
Alastair Rushworth had the answer: what’s the easiest way to access the knitr cache? It turns out all we need is the lazyLoad() function, and of course some detective work to find the right cache (but you’re labelling your chunks, aren’t you?).
So: lazyLoad("name-of-that-cached-rdx-file-in-the-cache"), and note that there is no file extension here…
This is something that nags me from time to time, particularly because it’s a documented feature I tend to forget. When using the split.screen() function of R to combine plots (rather than par(mfrow)) in Sweave or Knitr, the screen numbers are output in the main text, alongside the figure. Usually we want the figure only. All we need is adding results='hide'. I find this slightly counter-intuitive, because I do want the result (in form of a figure). That said, I don’t have a suggestion what alternative would feel more intuitive. The same issue also happens when using library(rgdal) for a local shapefile, and other similar situations.
No doubt Sweave is one of the pieces that makes R great. Sweave combines the benefits of R with those of LaTeX to enable reproducible research. Knitr is a more recent contribution by Yihui Xie, packing in the goodness of Sweave alongside cacheSweave, pgfSweave, RweaveHTML, HighlightWeaveLatex etc. It requires separate installation, interestingly also when using Rstudio.
As much as I like Sweave, I argue that often knitr is the better choice, despite there being no equivalent to R CMD Sweave --pdf. First of all, knitr uses Rmarkdown, a set of intuitive human-readable code to do the formatting. While LaTeX is by no means as complicated as its reputation seems to suggest, Rmarkdown is actually easy. By human-readable I mean that anyone who has never even heard of Rmarkdown can understand what is happening to some extent.
Sweave is great for producing PDF, but that’s one of the biggest drawbacks of LaTeX in the social sciences: while the PDF may look good, they are not the format we need when collaborating with Word-only colleagues, and with rare exceptions when submitting a manuscript to journals. Knitr works very well with Pandoc, so creating a Word document or an ODF is just as easy as creating a PDF. The other day I had to submit a supplementary file as a *.doc file, even though it’ll end up as a PDF on Dataverse or so. With knitr this didn’t take long.
What’s the catch then? Rmarkdown comes with a restricted set of commands, and there is no way to create custom commands. This isn’t a problem, though. For instance, if you create a PDF with knitr, you can include standard LaTeX code, like \newpage. More importantly, with a restricted set of commands, I find myself tinkering much less than what I do in LaTeX. In other words, with Rmarkdown and knitr, I do more of that purported benefit of LaTeX, namely concentrating on the contents rather than worrying about what it’ll end up looking. A more radical step would probably be writing in plain text and then finish it off in Word (or LibreOffice), because we seem to end up there anyway — at least at the submission stage.
There are two aspects where the restrictions of Rmarkdown are noticeable: references (roughly on par with Endnote, not with BibTeX), and complex tables. When it comes to complex tables, we should probably be thinking about graphs anyway. In this context, however, being human-readable highlights another advantage of knitr: if the document fails to compile, it’s much easier to debug (and here Sweave beats odfWeave by miles).
What neither approach resolves, however, is collaborating with the Word-only crowd who need the “track changes” feature.
Didier Ruedin 