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@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
Charles C. Berry (858) 534-2098
Dept of Family/Preventive Medicine
E mailto:cbe...@tajo.ucsd.edu UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
