I'm attaching my first knitr doc, which I rendered to
pdf from HTML because the HTML didn't seem to be robust
(more below). It explains how to fit soil carbon model
parameters for a simple two-compartment model with feedback
based on data from a controlled soil incubation experiment.
Hopefully I included enough of a brief of the science that
it's understandable. Any and all feedback on the models
welcome. This one's the industry standard model, so I wanted to
fit that first. Michael's already suggested going to a lognormal
noise to respect positivity constraints on concentrations, and that works
well. I also implemented a measurement error model a la 8 schools,
because the actual data is made up of sample means and standard
deviations from replicated experiments.
I got the hard sell on knitr from David LeBauer (cc-ed) when I was out
in Arizona (David --- if you want to respond, I can forward to our
developers group if you'd like; feel free to forward elsewhere), based on:
* reproducible science
* literate programming
* easier to learn than LaTeX
If you don't know what knitr is, it lets you write R "markdown"
(very similar to GitHub flavored "markdown") to generate either
an HTML or LaTeX (or even MSWord) document. The document generation
process is called "knitting" (should be "knittering"). And like
knitting, it's awfully slow, even compared to running pdflatex
multiple times as we do for our manual with indexes and cross-refs and
bibs.
The reproducibility is tantalizing. You can create an entire
sequence of operations and be sure that they run to produce the
right result. For that reason, I thought it might be a good way
to present our examples. Or write a textbook. We'd then have the
Stan code, R code, and doc all together and they'd be guaranteed
to be in synch. This is the big selling point for me.
I've been using LaTeX since 1984 (30 years!), so that's not an obstacle
for me. Rather, I like is that it lets you embed LaTeX!
knitr is NOT like IPython notebooks in that a person looking at the knitted
document can't change some of the params and rerun it. You have to download
the source, edit that, and then reknit the whole thing from scratch.
This wouldn't be a dealbreaker for my intended application to Stan examples, though,
and I went in knowing the score.
The major selling points of knitr are that
* if you include the right escapes around R code (and apparently
many other types), it will execute and the results will be dumped
into the output document, including figures, and
* if you use $...$, the formula making up the ellipses is converted
to MathJAX and used to render on the client side.
Rendering MathJAX on the client side is slow. I'm already tired of
watching Safari tell me how much progress I've made through it, and this
is only a small doc.
I'm not a big fan of "literate programming" if that means
mixing doc and code like this:
http://en.wikipedia.org/wiki/Literate_programming
It's convenient for small projects, but I don't see how it's going to scale.
It also makes it hard to edit the code as it's all in one big honking editor
in RStudio. Of course, I could edit the knitr source (format .Rmd for R markdown)
in emacs and then knit it from the command line using a script. There seem to
be some robustness issues with editing while knitting, but I'm not sure that
wasn't some other problem I fat fingered on the interface.
Mixing text and code isn't so pretty. I like my syntax highlighting and
I like to be able to see all the code I'm I'm working on at once without scrolling
around finding it interspersed with a textual exegesis. I favor modularity over
automatic gathering. I also like using one tool for everything. To pull our
a cooking example, I'm a chef's knife and simple stainless steel pan kind of guy,
not a gadget guy.
I like managing all of my code separately and using my favorite editor to edit
it and my favorite tools to run it, like make. It's a pain to get started that
way compared to just popping open a new markdown project in RStudio, but I think
the up front time is more than made up by everything then being easier downstream.
So I think I might like knitr better used outside of RStudio with
more use of includes and less of writing into a single document.
I had to write a little R script program just to dump unformatted code
into the document. There's probably a more elegant way, but I couldn't
find it.
I do not at all like the code editor or the R Markdown editor in RStudio.
I do appreciate the pop-up auto-complete and open global environment browser, given
how much R programming idioms (and even packages) lean on the global environment.
(And kudos to Jeffrey Arnold for getting that working in Stan's emacs mode, which
I love!)
I'm worried about applications of knitr to Stan because I couldn't figure out
how to get knitr's make-like behavior to cache the Stan fit object so that it
doesn't need to run each time. Might it be because there's an outside file referenced
in it? I can't bring myself to write my Stan program as a string embedded
in R code, but maybe that would work.
After two days, I'm not sold on RStudio (but then I came in with a very
anti-IDE prejudice). As to RStudio:
* It's unstable and not only crashed, but crashed my
whole OS (I'm also not a huge fan of Mac OS X "Yosemite").
Maybe that's what Andrew's problem has been! Avi Feller was saying
that RStan crashed in RStudio (not sure what hardware/OS), but never
when run from the command line under Linux on a cluster.
* RStudio gobbles some output, which I really don't like. Maybe
that's configurable?
* Like every other IDE, RStudio hides things and tries to be
clever by automatically foregrounding and backgrounding
windows and what not. To change metaphors to the automotive
industry (I am from Detroit), I prefer to shift myself because
I haven't met an auto transmission that does it better (I hear
they exist now --- I'm a New Yorker now and don't own a car and
only rent crap cars like the Chevy Malibu I had in Arizona.)
Also, what's with all these R package docs? I found the knitr
doc and web site, as it is, pretty much impenetrable.
http://yihui.name/knitr/
In that way, it's just like ggplot2 (another RStudio gig), meaning
that I had to go to third-person resources to figure it out. Good thing
there are so many great R tutorials out there!
Markdown. I really hate working in markdown. This goes for
WordPress, which uses WordPress markdown, and GitHub Wiki and issues,
which use GitHub "flavored" markdown. I'd rather just write the HTML since
I'm going to have to figure out how it renders the HTML anyway
if I want a reasonable output.
The rendering of HTML and LaTeX is not seamless. I wound up having to
write a gazillion straight-up HTML elements and styles to do things like float and
size pictures or to include captions. That's an example of what I mean when I
say these markdown languages make easy things easier and hard things harder.
As a result, not everything shows up in LaTeX. You can also write
in pseudo-LaTeX and have things rendered to HTML with the opposite
problem. Or you can take a least-common denominator approach and get
ill-formatted docs both ways, but at least they'll be the same.
What's up with those awful knitr style sheets? They violate standard
rules of typesetting like making headers closer to the text they
head than the text they follow. Are there better ones somewhere
someone could recommend? I do like that you can drop in your own stylesheet.
Then you just need to learn what knitr renders in the way of HTML
(just kidding --- this is why I don't like "clever" tools getting in
the way of my code; if I wrote straight up HTML this issue goes away).
I sent my completely knitted doc to Rob, and he couldn't render
it on his machine. Things seem to be messed up in both fonts and in
content. Maybe the former is due to missing a char encoding declaration.
Odd, because it makes a 3MB web page that has everything inside it as data.
You'd think they'd control the fonts. Now why you get what look like stub
captions when Rob renders it, I don't know.
At some point in Arizona, someone (maybe David) mentioned that they liked
that you don't have to paginate knitr output. That does seem like a plus for
code and its output.
- Bob