[Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?
Charles C. Berry
cberry at tajo.ucsd.edu
Fri Aug 20 06:26:19 CEST 2010
On Thu, 19 Aug 2010, Kevin Coombes wrote:
> 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.
>
emacs org-mode might help.
You can define a chunk, <<ch1>> (say), then place it in a subsequent
chunk, <<ch2>> (say), inside an eval() and refer to <<ch2>> inside an
eval() inside another chunk, <<ch3>>, and so on. The only trick is to
write the chunk so that the chunk it refers to is on its own line, like
this:
#+source: ch3
#+begin_src R :session :noweb yes
eval(
<<ch2>>
)
z <- mean(y)+1
#+end_src
as the noweb expansion will repeat any other text on the line with the
named chunk for each line of code in the referenced chunk.
You can define a library of chunks separately, which might help you if you
reuse them in different places.
You can use ess-mode to edit the chunks and execute them with the usual
ess-eval-* commands, or run them in org-mode with the results optionally
returned to the edit buffer, but outside the code block.
If you want to debug a bunch of nested chunks and 'step through the code
during development', you can tangle the chunk you wish to execute to
produce a *.R file. The nested chunks are expanded into R. Open that *.R
file and debug away.
With a recent emacs, I think this gets you going:
C-h i m Org Mode RET C-s source RET RET
or Google 'org-babel R' or some such or just go look here:
http://blogisticreflections.wordpress.com/
> 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...
org-mode might be the path of least resistance.
FWIW, the code chunks are objects processed by emacs-lisp before they are
handed off to R, so there might be a slicker way to handle the nesting
than dropping chunks inside eval()s in R blocks. If that interests you,
there is a very active listserv for orgmode, where you might inqure.
HTH,
Chuck
>
> 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 at r-project.org mailing list
>> > > https://stat.ethz.ch/mailman/listinfo/r-devel
>> > >
>> > ______________________________________________
>> > R-devel at r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
Charles C. Berry (858) 534-2098
Dept of Family/Preventive Medicine
E mailto:cberry at tajo.ucsd.edu UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
More information about the R-devel
mailing list