What do Sweave/knitr offer that make doesn't?

Question

I use LaTeX to write papers and R for data analysis and visualization, so I've been looking into Sweave and knitr.

The Sweave website says:

The purpose is to create dynamic reports, which can be updated automatically if data or analysis change.

But it seems to me that I already have this in my current workflow, with a makefile that runs my R scripts and then compiles my LaTeX with the figures and tables generated by the scripts.

The make approach is also really good with caching, e.g., it checks the timestamps of my data files as well as source files to know when to recompile individual components.

And it seems like with Sweave/knitr, I lose ability to run just my R or my LaTeX, separately.

Am I missing something? What do solutions like Sweave and knitr offer that make doesn't?

Answer 1

I'm still new to LaTeX (about 2 years of use) but have found knitr very helpful for:

• inline code
• code chunks - incredibly helpful for execution and then interspersing your document with it
• dead simple graph integration into document
• caching (I'm sure you could do this with make by watching file changes)
• an amazingly responsive support community (at least on #r on freenode)

From the knitr website:

knitr ≈ Sweave + cacheSweave + pgfSweave + weaver + animation::saveLatex + R2HTML::RweaveHTML + highlight::HighlightWeaveLatex + 0.2 * brew + 0.1 * SweaveListingUtils + more

I do however use the now considered outdated rubber for compilation, so I'm sure others can provide more context with regards to make specifically.

Answer 2

If you want only include some tables and figures in your LaTeX document, the literate programming paradigm, in this case with Sweave\knitr, could be a little advantage.

But in large documents is tremendously useful see what you wrote in LaTeX about your statistics tests, tables and figures near of the related R chunk producing these results. In this way R chunks are often self-explained, so you do not need most comments of the R script.

More importantly,if your run R separately, you can update tables and figures, but not what have you wrote in LaTeX about this results. For example: you have information about the vector a that is c(2,3,4,5) in some table or figure (said a box plot):

a <- c(2,3,5,7)
boxplot(a)

Accordingly, you wrote in LaTeX that

...the mean of $a$ was 4.25 and ... 

All is OK, but later you change this vector in your R script to:

a <- c(2,3,4,7)

After re-run R and LaTeX, your boxplot is updated but the mean in the text is still 4.25 (instead of 4). What now? You need make a deep review of your text to change mistakes as this.

Instead, with Sweave, if you have the correct data you can always show the correct box plot and the correct mean:

<<myboxplot,fig=T>>=
`a <- c(2,3,5,7)`
boxplot(a)
@
 ...the mean of $a$ was \Sexpr{mean(a)} and ...

Imagine now a text with dozen of p-values among the text like:

... the t-test of $a$ was significant (p=0.0312) ... 

The manual update could be a nightmare. But the automatic update is easy:

... the t-test of $a$ was significant (p=\Sexpr{round(t.test(a)$p.value},3))...

Moreover, this way you can be 100% sure of what are you showing in the PDF. In other case, may be 0.0312 was pasted from the wrong test in the R commander.

One can argue that if the vector a change to some like c(-2,3,4,7) then the p value will be updated correctly to 0.207 but not the meaning of the relative LaTeX text (because now 0.207 is "not significant") but note that the automatic update is not limited to tables, figures and numeric values within the text. You can make also an R object (said statsig) that conditionally have the string "significant" or "not significant" according to t.test(a)$p.value and print as a S expression:

... the t-test of $a$ was \Sexpr{print(statsig)} (p=\Sexpr{t.test(a)$p.value}) ...

May be too much work for an article with already obtained data without expected updates ... but imagine that your LaTeX document is a daily report of the results of some laboratory method ...it worth it?

Answer 3

Forkrul covered most of the big issues. I would add:

fine-grained caching of R code

If you change one line of code in a single chunk, the rest of your document cache remains in place. I assume with make you can't cache part of the output of a long R script - if you make one change in the file, the entire file needs to be rerun.

manage code and text without switching context

Sure, you can use make to run R, then follow that by running LaTeX. But you are still required to maintain at least two files by hand - your .R and your .tex. With knitr you do it all from within a single file. This reduces the cost of the context switch every time you move from .tex to .R. If you've got Emacs nicely tuned, that cost may be small, but I don't think it's zero.

separate code from text on demand

You can still run your R code on its own. Emacs and Rstudio both provide an interface to send your R code from your Rnw document directly to the R interpreter. You don't need to generate the tex file if you just want to check a value. You can also extract all the R code from the document, should you want a plain .R file. (via the purl() function from knitr).

It is true that you can't run LaTeX without running knitr/R, but in this context it's no longer useful to do so. You don't touch the .tex file by hand anymore, instead you generate your pdf directly from the .R file.

collaborate with colleagues that don't know LaTeX

knitr supports Markdown as well as LaTeX, which makes it much more accessible to non-LaTeX using colleagues. I have had some success using knitr to sell reproducible research to peers who would never consider investing the time to learn LaTeX. I also have some hope that knitr will be the gateway drug that helps pull more people into LaTeX ;)