I picked the example from segmenting chromosomes for a reason. I have a
fair chunk of code that deals with not quite exceeding the amount of RAM
available in the machine sitting on my desktop. If I use functions,
then the pass-by-value semantics of R will push me beyond the limits at
some points. (This is an empirical statement, not a theoretical one. I
was bitten by it several times while trying to analyze a couple of these
datasets. And, yes, I know I can get around this by buying a bigger and
better machine; it's on order...) The real point is that using
functions can be detrimental to the efficiency of the program, in ways
that have real world consequences.
I haven't thought about doing the same thing with expressions.
Expressions don't have quite the same semantics as chunks, and you'd
have to make sure the evaluation was delayed so that you cold use the
current values of things that were computed in the meantime.... and I
already know how to do this with chunks without having to think so hard.
Using expressons would, however, help with the one difficulty that I
have with reusing <<chunks>> (independent of whether or not I use
'expand=FALSE'). I usually work inside emacs, using the
emacs-speaks-statistics (ESS) package. ESS doesn't know how to evaluate
the <<chunk>> call inside another chunk. so if I want to step through
the code during development, I have to jump around myself to locate the
source chunks. With expressions that wouldn't matter.
As I ramble on about this, it occurs to me that the underlying issue is
that <<chunks>> are not first class objects either in the LaTeX world or
in the R world part of Sweave. If there were a way to promote them to
first class objects somehow, then it might make my use of ESS easier
while simultaneously making it easier for Duncan to figure out how to
report the correct line numbers. But I only have an extremely vague
idea of how one might start to do that...
Kevin
Matt Shotwell wrote:
On Thu, 2010-08-19 at 17:07 -0400, Kevin Coombes wrote:
I use it, frequently. The idea for it goes back to some of Knuth's
original literate programming ideas for developing weave and tangle when
he was writing TeX (the program). I want to be able to document the
pieces of some complex algorithm without having to see all of the gory
details. For instance, I have code that looks like the following.
(Note that this is typed on the fly rather than copied from actual
source, so there may be typos.)
<<mainloop,keep.source=TRUE,expand=FALSE>>=
for (i in 1:nSamples) {
<<getInfoAboutThisSample>>
for (j in 1:nChromosomes) {
<<getChromosomeDataForCurrentSample>>
<<normalizeChromosomeData>>
<<findSegments>>
<<computeSignificance>>
<<writeResults>>
}
}
@
Each of the <<chunks>> is itself a fairly long piece of code defined and
documented somewhere else. (Some of them may themselves be written in
the same form to reduce the final size of a chunk to something a human
has a chance of understanding. That's the difference between weave and
tangle in the original implementation.) By blocking expansion, I can
focus on the main steps without having them lost in pages and pages of code.
Couldn't you achieve the same amount of abstraction using function
calls, rather than embedded code chunks? The reader can then see real
code, rather than non-code, or meta-code, or whatever. Alternatively,
represent the code chunks as R expressions, then evaluate the
expressions at the appropriate points.
-Matt
So I vote strongly for retaining "expand=FALSE".
Best,
Kevin
Duncan Murdoch wrote:
On 19/08/2010 4:29 PM, Claudia Beleites wrote:
I never used it.
I got curious, though. What would be a situation that benefits of
this option?
When I put it in, I thought it would be for people who were writing
about Sweave.
Duncan Murdoch
Maybe a use case could be found by "brute force" (grep all .Rnw files
on CRAN for the option?
Claudia
______________________________________________
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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
