Skip to content

odfWeave - A loop of the "same" data

4 messages · Polwart Calum (County Durham and Darlington NHS Foundation Trust), Jeff Newmiller, Charles C. Berry +1 more

Before I go and do this another way - can I check if anyone has a way of looping through data in odfWeave (or possibly sweave) to do a repeating analysis on subsets of data?

For simplicity lets use mtcars dataset in R to explain.  Dataset looks like this:
mpg cyl disp  hp drat   wt ...
Mazda RX4     21.0   6  160 110 3.90 2.62 ...
Mazda RX4 Wag 21.0   6  160 110 3.90 2.88 ...
Datsun 710    22.8   4  108  93 3.85 2.32 ...
               ............

Say I wanted to have a 'catalogue' style report from mtcars, where on each page I would perhaps have the Rowname as a heading and then plot a graph of mpg highlighting that specific car

Then add a page break and *do the same for the next car*.  I can manually do this of course, but it is effectively a loop something like this:

for (n in length(mtcars$mpg)) {
barplot (mtcars$mpg, col=c(rep(1,n-1),2,rep(1,length(mtcars$mpg)-n)))
}

There is a odfWeave page break function so I can do that sort of thing (I think).  But I don't think I can output more than one image can I?  In reality I will want several images and a table per "catalogue" page.

At the moment I think I need to create a master odt document, and create individual catalogue pages.  And merge them into one document - but that feels clunky (unless I can script the merge!)

Anyone got a better way?




********************************************************************************************************************

This message may contain confidential information. If yo...{{dropped:21}}
#
I do this regularly with knitr [1]. I have never used odfWeave, but would imagine that similar principles apply. 

If you make a child document that assumes that the desired data are stored in one or more objects, then you can use a for loop in the master document that repeatedly extracts the desired subsets and puts them into the objects the child document expects them to be in, parses the child document, and then "cat"s the parsed results into the master document output.

[1] https://yihui.name/knitr/demo/child/
#
On Thu, 1 Jun 2017, POLWART, Calum (COUNTY DURHAM AND DARLINGTON NHS FOUNDATION TRUST) via R-help wrote:

            
For a complex template inside a loop, I'd probably do as Jeff suggests and 
use a knitr child document for ease of developing and debugging the 
template.

But for the simple case you describe I'd use a brew script to
unroll the loop.

You would write your input file as usual, but put a brew script in the
right place, then run brew on the input file to produce an
intermediate file that unrolls the loop, then weave the intermediate
file to get your desired result.  Here is a simple example of such you 
can run in an R session (assuming the brew package is installed) and see 
the results printed out.

--8<---------------cut here---------------start------------->8---

brew::brew(text="

Everything before the loop

<% for (i in 1:10) { %>
Print the value of i
<% print(i) %> or better yet
\\Sexpr{<%= i %>}
<% } %>

everything after

")

--8<---------------cut here---------------end--------------->8---

The double backslash is needed in the literal string used here.  If
you put that script in a file using an editor, you would just use a
single backslash.

HTH,

Chuck
#
This is what the R.rsp (https://cran.r-project.org/package=R.rsp; I'm
the author) and it's RSP markup is good at and was designed to handle.
We're using it lots in report generation where we iterate of elements,
e.g. over the 24 chromosomes.  See Section 2.3 in
https://cran.r-project.org/web/packages/R.rsp/vignettes/Dynamic_document_creation_using_RSP.pdf.
RSP is independent of input format - all it requires is that it's
text-based - so you can use RSP-embedded LaTeX, HTML, Markdown, ...,
and even RSP-embedded Sweave, knitr, Rmarkdown (where it then it
effectively works as a pre-processor to those formats).

Hope this helps

Henrik
On Thu, Jun 1, 2017 at 9:35 AM, Charles C. Berry <ccberry at ucsd.edu> wrote: