[Rd] Deprecation of "--min-nsize" and "--min-vsize"
Hi R-devel,
I only run the released version of R where "--min-nsize" and
"--min-vsize" have now been deprecated, and am told that this
functionality has been removed in the dev-version. However, having R
not repeatedly ask the operating system for more memory while
executing, and raising the "gc trigger" level so that garbage
collection is postproned, is a time-wise effective way of running R
scripts. Of course, you need a system that can handle the larger
memory footprint.
Here is an example:
--
gc(); system.time({
N = 200;
SUBLENGTH <- rep(3, N);
CONEVAL <- matrix(1:(3*N), ncol=3);
cones <- matrix(list(), nrow=2, ncol=N, dimnames=list(c("type","sub"),c()));
for (i in 1:N) {
cones[,i] <- list("MSK_CT_QUAD", CONEVAL[i,]);
}
}) gc();
--
Normal execution:
user system elapsed
28.030 0.190 28.238
With high values of "--min-nsize" and "--min-vsize":
user system elapsed
10.330 1.130 11.464
So the effect is a factor 2 to 3. I agree that these arguments are too
technical for the average user and that you would rarely really need
them, but it would be nice to have an easy way of speeding up R
scripts. Also, setting high values of "--min-nsize" and "--min-vsize"
gives more consistent system.time() results when more methods are
tested after each other, because garbage collection and the
availability of memory in the R process does not interfere.
Take this as a thought, and not a need-to-have from my side..
Kind regards,
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk GUIs (was need gui matrix editor: does R Core team have advice on how?)
On 1/29/2012 4:35 PM, Paul Johnson wrote: On Sun, Jan 29, 2012 at 6:10 AM, Prof Brian Ripley wrote: On 28/01/2012 22:04, John Fox wrote: Dear Paul and Gabor, The Rcmdr GUI uses the tcltk package, so I have some experience with providing an R tcltk-based GUI for various platforms. As Gabor says, everything works very smoothly on Windows because the R Windows binary includes Tcl/Tk. Maybe, but getting it there was very far from smooth. Tcl/Tk compiled under the compilers we used, but the resulting DLLs crashed R. No one has ever found the cause and I used the system SDK (essentiallly a version of VC++) to build them. And that puts us in a bind since the current system SDKs generate code depending on DLLs that are not part of the minimal OS versions we support (e.g. Windows XP and Server 2003, and the machine used to build was retired 2 years ago). Thanks, this is clearing things up. I believe these comments mean that, at the current time, tcl/tk is as close as there is to an officially endorsed graphical toolkit. As I search more, I find many other community contributors (besides Prof. Fox) using tcl/tk (Sciviews). So I should learn how to work with that. Prof Ripley's comment makes me think the endorsement is not entirely enthusiastic, though. There's this famous quotation from Winston Churchill: "it has been said that democracy is the worst form of government except all those other forms that have been tried." Using Tcl/Tk in R is similar. It's there, and the R Core team (mostly) makes sure it works cross-platform, so it is the obvious choice for GUI development in R. But it is far from perfect. For one thing, the documentation in R is quite limited. The manual pages list all of the functions in the tcltk package, but they basically take "..." as their arguments. As a result, you sometimes have to guess how to get the inputs formatted correctly to pass them back-and-forth between the R process and the Tcl/Tk process (which have very different syntax). For another thing, communication between the two processes (at least on Windows) sometimes breaks down in non-reproducible and hard-to-debug ways. We built a tcltk GUI that uses a tabbed notebook interface, which is supposed to display five tabs. Most of the time, it does. But it can end up displaying anything from 1 to 5 tabs. It always displays them in order, so it apparently runs into a problem at some random point and stops. Closing the GUi and restarting it usually fixes the problem. Since we cannot trigger it reproducibly, we have never found the underlying source of the problem. This message is not meant to dissuade you from using Tcl/Tk. It's just a warning to expect some bumps along the way Good luck, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Help page of colors() : add a new example ?
Dear all,
May I suggest to add an example in the help page of the colors() function ?
The following code could be useful to easily choose any color from colors() :
## Millot G. (2011), p.71.
## Figure displaying all the 657 built-in color names of colors().
palette(colors())
tempo<-NULL
for(i in 14:1){tempo<-c(tempo, rep(i,50))}
windows(width=10) # replace by quartz(width=10) for MacOS and by X11(width=10)
for Linux
par(ann=FALSE, xaxt="n", yaxt="n", bty="n")
plot(rep(1:50,14)[1:657], tempo[1:657], pch=22, bg=1:657, cex=1.5, bty="n")
par(xpd=TRUE)
axis(side=2, at=14:1, labels=, cex.axis=1.5, srt=90)
text(rep(-2, 14), 14:1, as.character((0:13)*50+1), srt=0, cex=1)
text(c(10,20,30,40,50), rep(-0.5,5), c(10,20,30,40,50), srt=0, cex=1)
## palette(colors()) allow to replace the color names by the numbers indicated
## in the figure.
palette(colors())
plot(1, col=630, pch=16, cex=10) # 630 is "tomato"
This code comes from the page 71 of the book I published in french:
Millot G. Comprendre et réaliser les tests statistiques à l'aide de R, 2nd
edition. De Boeck editions, Bruxelles . 2011, 767 pages.
I wrote it since my students usually complain about the difficulty to select a
color
from colors() when the names are displayed.
Kind regards,
Gael Millot.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk GUIs (was need gui matrix editor: does R Core team have advice on how?)
On 30/01/2012 9:17 AM, Kevin R. Coombes wrote: On 1/29/2012 4:35 PM, Paul Johnson wrote: > On Sun, Jan 29, 2012 at 6:10 AM, Prof Brian Ripley > wrote: >> On 28/01/2012 22:04, John Fox wrote: >>> Dear Paul and Gabor, >>> >>> The Rcmdr GUI uses the tcltk package, so I have some experience with >>> providing an R tcltk-based GUI for various platforms. >>> >>> As Gabor says, everything works very smoothly on Windows because the R >>> Windows binary includes Tcl/Tk. >> >> Maybe, but getting it there was very far from smooth. Tcl/Tk compiled under >> the compilers we used, but the resulting DLLs crashed R. No one has ever >> found the cause and I used the system SDK (essentiallly a version of VC++) >> to build them. And that puts us in a bind since the current system SDKs >> generate code depending on DLLs that are not part of the minimal OS versions >> we support (e.g. Windows XP and Server 2003, and the machine used to build >> was retired 2 years ago). >> > Thanks, this is clearing things up. I believe these comments mean > that, at the current time, tcl/tk is as close as there is to an > officially endorsed graphical toolkit. As I search more, I find many > other community contributors (besides Prof. Fox) using tcl/tk > (Sciviews). So I should learn how to work with that. Prof Ripley's > comment makes me think the endorsement is not entirely enthusiastic, > though. There's this famous quotation from Winston Churchill: "it has been said that democracy is the worst form of government except all those other forms that have been tried." Using Tcl/Tk in R is similar. It's there, and the R Core team (mostly) makes sure it works cross-platform, so it is the obvious choice for GUI development in R. But it is far from perfect. For one thing, the documentation in R is quite limited. The manual pages list all of the functions in the tcltk package, but they basically take "..." as their arguments. As a result, you sometimes have to guess how to get the inputs formatted correctly to pass them back-and-forth between the R process and the Tcl/Tk process (which have very different syntax). For another thing, communication between the two processes (at least on Windows) sometimes breaks down in non-reproducible and hard-to-debug ways. We built a tcltk GUI that uses a tabbed notebook interface, which is supposed to display five tabs. Most of the time, it does. But it can end up displaying anything from 1 to 5 tabs. It always displays them in order, so it apparently runs into a problem at some random point and stops. Closing the GUi and restarting it usually fixes the problem. Since we cannot trigger it reproducibly, we have never found the underlying source of the problem. This message is not meant to dissuade you from using Tcl/Tk. It's just a warning to expect some bumps along the way Just one addition: the full Tcl/Tk documentation should be available to most users. It is included in the Windows distribution (and referenced from the ?tcltk help page) and I would guess other platforms install it when they install Tcl/Tk. It is written assuming that you're writing in Tcl rather than R, but once you work out the translation, it's actually somewhat usable. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] zip() containing windows specific code?
Dear R devel list
I was wondering whether zip() contains a windows specific call to
system(), as the argument "invisible" seems to be windows specific, yet
is used anytime by zip:
invisible(system2(zip, args, invisible = TRUE))
Indeed, calling zip() on Linux results in a warning message:
file.create("try")
[1] TRUE
zip("try.zip", "try")
adding: try (stored 0%)
Message d'avis :
In system2(zip, args, invisible = TRUE) :
arguments 'minimized' and 'invisible' are for Windows only
unlink("try")
Best
Matthieu
> sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=fr_FR.UTF-8 LC_NUMERIC=C
[3] LC_TIME=fr_FR.UTF-8LC_COLLATE=fr_FR.UTF-8
[5] LC_MONETARY=fr_FR.UTF-8LC_MESSAGES=en_US.utf8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] colorout_0.9-9
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] panel.first for bxp
I am intrigued why bxp does not support panel.first in order to draw a grid
behind the boxplots. The advice given here:
https://stat.ethz.ch/pipermail/r-help/2006-April/104608.html
seems utterly bogus, and the result is noticeably different in PDF.
I would propose the following patch, which follows what is done for
plot.default. If it is ok, I can produce also patches for the documentation.
Please apply to:
https://svn.r-project.org/R/trunk/src/library/graphics/R/boxplot.R
Cheers,
Manuel.
--- boxplot.R 2011-12-02 14:22:10.0 +0100
+++ boxplot-grid.R 2012-01-30 18:19:18.400445423 +0100
@@ -108,7 +108,8 @@
bxp <- function(z, notch=FALSE, width=NULL, varwidth=FALSE, outline = TRUE,
notch.frac = 0.5, log = "", border=par("fg"),
pars = NULL, frame.plot = axes, horizontal = FALSE,
- add = FALSE, at = NULL, show.names = NULL, ...)
+ add = FALSE, at = NULL, show.names = NULL,
+panel.first = NULL, ...)
{
pars <- c(list(...), pars)
## this could give duplicates, so ensure first mentioned wins.
@@ -219,6 +220,7 @@
plot.window(ylim = xlim, xlim = ylim, log = log, xaxs = pars$yaxs)
else
plot.window(xlim = xlim, ylim = ylim, log = log, yaxs = pars$yaxs)
+panel.first
}
xlog <- (par("ylog") && horizontal) || (par("xlog") && !horizontal)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave driver extension
I prefer the code chunks myself.
Function calls have overhead. In a bioinformatics world with large
datasets and an R default that uses call-by-value rather than
call-by-reference, the function calls may have a _lot_ of overhead.
Writing the functions to make sure they use call-by-reference for the
large objects instead has a different kind of overhead in the stress it
puts on the writers and maintainers of code.
But then, I'm old enough to have looked at some of Knuth's source code
for TeX and read his book on Literate Programming, where the ideas of
"weave" and "tangle" were created for exactly the kind of application
that Terry asked about. Knuth's fundamental idea here is that the
documentation (mainly the stuff processed through "weave") is created
for humans, while the executable code (in Knuth's view, the stuff
created by "tangle") is intended for computers. If you want people to
understand the code, then you often want to use a top-down approach that
outlines the structure -- code chunks with forward references work
perfectly for this purpose.
One of the difficulties in mapping Knuth's idea over to R and Sweave is
that the operations of weave and tangle have gotten, well, tangled.
Sweave does not just prepare the documentation; it also executes the
code in order to put the results of the computation into the
documentation. In order to get the forward references to work with
Sweave, you would have to makes two passes through the file: one to make
sure you know where each named chunk is and build a cross-reference
table, and one to actually execute the code in the correct order. That
would presumably also require a major rewrite of Sweave.
The solution I use is to cheat and hide the chunks initially and reveal
them later to get the output that want. This comes down to combining
eval, echo, keep.source, and expand in the right combinations. Something
like:
% set up a prologue that contains the code chunks. Do not evaluate or
display them.
<>=
# do something sensible. If multiple steps, define them above here
# using the same idea.
@
% also define the other code chunks here
\section{Start the First Section}
The \texttt{coxme} function is defined as follows:
<>=
coxme <- function(formula, data, subset, blah blah ){
<>
<>
<>
<>
}
@
Argument checking is important:
<>=
<>=
@
% Describe the other chunks here
Kevin
On 1/24/2012 10:24 PM, Yihui Xie wrote:
Maybe this is a my personal taste: I do not like pseudo R code in the
form<> inside a chunk, and I'm curious about why you do
not use real R functions to do the job.
coxme<- function(formula, data, subset, blah blah ){
coxme_check_arguments(...)
coxme_build(...)
coxme_compute(...)
coxme_finish(...)
}
You can define these coxme_xxx functions later in the parent
environment. It is also easy for one function to call another, so the
recursion is natural. Compared to text-processing tricks, I prefer
well-defined functions.
Your idea of using a named list to store R code is what I used in the
knitr package (http://yihui.github.com/knitr/demo/reference/), e.g.
% empty here
<>=
@
% real code is defined here
<>=
rnorm(10)
@
The second chunk appears later, but when you weave the document, the
code rnorm(10) will also go to the first chunk since the label
'chunk1' will index the code from the second chunk.
Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Tue, Jan 24, 2012 at 1:50 PM, Terry Therneau wrote:
Almost all of the coxme package and an increasing amount of the survival
package are now written in noweb, i.e., .Rnw files. It would be nice to
process these using the Sweave function + a special driver, which I can
do using a modified version of Sweave. The primary change is to allow
the following type of construction
<>
coxme<- function(formula, data, subset, blah blah ){
<>
<>
<>
<>
}
@
where the parts referred to come later, and will themselves be made up
of other parts. Since the point of this file is to document source
code, the order in which chunks are defined is driven by "create a
textbook" thoughts and won't match the final code order for R.
The standard noweb driver only allows one level of recursion, and no
references to things defined further down in the file.
The primary change to the function simply breaks the main loop into
two parts: first read through the all the lines and create a list of
code chunks (some with names), then go through the list of chunks and
call driver routines. There are a couple of other minor details, e.g. a
precheck for infinite recursions, but no change to what is passed to the
driver routines, nor to anything but the Sweave function itself.
Primary question: who on the core team should I be holding this
conversation with?
Secondary: Testing level? I have a few vignettes but not many.
I'll need a "no
Re: [Rd] zip() containing windows specific code?
On 30/01/2012 17:24, Matthieu Stigler wrote:
Dear R devel list
I was wondering whether zip() contains a windows specific call to
system(),
Actually, it does not contain a call to system()
as the argument "invisible" seems to be windows specific, yet
is used anytime by zip:
And what is your problem here? R ignores the arguments to systems()
where not needed.
invisible(system2(zip, args, invisible = TRUE))
Indeed, calling zip() on Linux results in a warning message:
file.create("try")
[1] TRUE
zip("try.zip", "try")
adding: try (stored 0%)
Message d'avis :
In system2(zip, args, invisible = TRUE) :
arguments 'minimized' and 'invisible' are for Windows only
unlink("try")
Best
Matthieu
> sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=fr_FR.UTF-8 LC_NUMERIC=C
[3] LC_TIME=fr_FR.UTF-8 LC_COLLATE=fr_FR.UTF-8
[5] LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES=en_US.utf8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] colorout_0.9-9
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help page of colors() : add a new example ?
Gael,
Your graph has a lot of white space. Is that intentional? I've seen
similar code in other places that uses less white space.
Here's another option for choosing ANY color, not just pre-defined colors.
require(tcltk)
tclvalue(tcl("tk_chooseColor"))
Kevin
On Mon, Jan 30, 2012 at 8:46 AM, Millot Gael wrote:
> Dear all,
>
> May I suggest to add an example in the help page of the colors() function ?
> The following code could be useful to easily choose any color from
> colors() :
>
> ## Millot G. (2011), p.71.
> ## Figure displaying all the 657 built-in color names of colors().
> palette(colors())
> tempo<-NULL
> for(i in 14:1){tempo<-c(tempo, rep(i,50))}
> windows(width=10) # replace by quartz(width=10) for MacOS and by
> X11(width=10) for Linux
> par(ann=FALSE, xaxt="n", yaxt="n", bty="n")
> plot(rep(1:50,14)[1:657], tempo[1:657], pch=22, bg=1:657, cex=1.5, bty="n")
> par(xpd=TRUE)
> axis(side=2, at=14:1, labels=, cex.axis=1.5, srt=90)
> text(rep(-2, 14), 14:1, as.character((0:13)*50+1), srt=0, cex=1)
> text(c(10,20,30,40,50), rep(-0.5,5), c(10,20,30,40,50), srt=0, cex=1)
>
> ## palette(colors()) allow to replace the color names by the numbers
> indicated
> ## in the figure.
> palette(colors())
> plot(1, col=630, pch=16, cex=10) # 630 is "tomato"
>
> This code comes from the page 71 of the book I published in french:
> Millot G. Comprendre et réaliser les tests statistiques à l'aide de R, 2nd
> edition. De Boeck editions, Bruxelles . 2011, 767 pages.
>
> I wrote it since my students usually complain about the difficulty to
> select a color
> from colors() when the names are displayed.
>
> Kind regards,
>
> Gael Millot.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Kevin Wright
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical instability in new R Windows development version
This did turn out to be a bug in the new toolchain, and Brian Ripley has devised a patch and put together a new one. I've uploaded a new Rtools215.exe, which should be available for download tomorrow, and builds of R-patched and R-devel will soon use it. Everything takes a while to propagate to the volunteers and systems that build binaries and the mirrors, but we should all be up to date by the end of the week or so. Thanks for the report! Duncan Murdoch On 27/01/2012 7:23 AM, Hans W Borchers wrote: I have a question concerning the new Windows toolchain for R>= 2.14.2. When trying out my package 'pracma' on the win-builder development version it will stop with the following error message: > f3<- function(x, y) sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) > dblquad(f3, -1, 1, -1, 1) # 2.094395124 , i.e. 2/3*pi , err = 2e-8 Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced Error in integrate(function(y) f(x, y), ya, yb, subdivisions = subdivs, : non-finite function value Calls: dblquad ... -> f -> do.call -> mapply ->-> integrate Execution halted ** running examples for arch 'x64' ... ERROR Running examples in 'pracma-Ex.R' failed This probably means that the following expression got negative for some values x, y: (1 - (x^2 + y^2)) * (x^2 + y^2<= 1) It appears to be an often used trick in numerical analysis. One advantage is that a function using it is immediately vectorized while an expression such as, e.g., "max(0, 1 - (x^2 + y^2))" is not. The example runs fine on Debian Linux and Mac OS X 32-/64-bit architectures. In my understanding the approach is correct and, as said above, often used in numerical applications. Can someone explain to me why this fails for the Windows 64-bit compiler and what I should use instead. Thanks. Hans Werner Borchers ABB Corporate Research __ 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
Re: [Rd] Help page of colors() : add a new example ?
Here's another graphic that shows R colors in a table, from Earl Glynn
of the Stowers Institute of Medicine:
http://research.stowers-institute.org/efg/R/Color/Chart/
If the link doesn't bring up the page (my didn't initially), Google on
'Earl Glynn Stowers' and look for the link 'Chart of R Colors'.
Dennis
On Mon, Jan 30, 2012 at 6:46 AM, Millot Gael wrote:
> Dear all,
>
> May I suggest to add an example in the help page of the colors() function ?
> The following code could be useful to easily choose any color from colors() :
>
> ## Millot G. (2011), p.71.
> ## Figure displaying all the 657 built-in color names of colors().
> palette(colors())
> tempo<-NULL
> for(i in 14:1){tempo<-c(tempo, rep(i,50))}
> windows(width=10) # replace by quartz(width=10) for MacOS and by
> X11(width=10) for Linux
> par(ann=FALSE, xaxt="n", yaxt="n", bty="n")
> plot(rep(1:50,14)[1:657], tempo[1:657], pch=22, bg=1:657, cex=1.5, bty="n")
> par(xpd=TRUE)
> axis(side=2, at=14:1, labels=, cex.axis=1.5, srt=90)
> text(rep(-2, 14), 14:1, as.character((0:13)*50+1), srt=0, cex=1)
> text(c(10,20,30,40,50), rep(-0.5,5), c(10,20,30,40,50), srt=0, cex=1)
>
> ## palette(colors()) allow to replace the color names by the numbers indicated
> ## in the figure.
> palette(colors())
> plot(1, col=630, pch=16, cex=10) # 630 is "tomato"
>
> This code comes from the page 71 of the book I published in french:
> Millot G. Comprendre et réaliser les tests statistiques à l'aide de R, 2nd
> edition. De Boeck editions, Bruxelles . 2011, 767 pages.
>
> I wrote it since my students usually complain about the difficulty to select
> a color
> from colors() when the names are displayed.
>
> Kind regards,
>
> Gael Millot.
>
> __
> 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
[Rd] Crash when using embedded R.
Hi, I'm new to R, and am trying to embed R into another application. I'm calling gev.fit() from the ismev package, and it is crashing somewhere inside it. gdb is not catching it, and valgrind is not showing any memory corruption issues. I suspect it's memory corruption, because it doesn't die in exactly the same spot each time. Also, before I make the gev.fit() call, I save out the R state using "save.image()", then load the image file, and call gev.fit(), and it works fine. So, it's something to do with my app, and the R. I'm looking for hints/ideas/tricks/etc for debugging this. I'm starting to put print statements into the R code, and into the C code in R (src/main/optim.c), but it hasn't shown me the source of the problem. Thanks! Dave [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave driver extension
OK, I did not realize the overhead problem is so overwhelming in your
situation. Therefore I re-implemented the chunk reference in the knitr
package in another way. In Sweave we use
<>=
# code in chunk a
@
<>=
# use code in a
<>
@
And in knitr, we can use real R code:
<>=
# code in chunk a
@
<>=
# use code in a
run_chunk('a')
@
This also allows arbitrary levels of recursion, e.g. I add another
chunk called 'c':
<=
run_chunk('b')
@
Because b uses a, so when c calls b, it will consequently call a as well.
The function run_chunk() will not bring overhead problems, because it
simply extracts the code from other chunks and evaluates it here. It
is not a functional call. This feature is still in the development
version (well, I did it this afternoon):
https://github.com/yihui/knitr.
--
Talking about Knuth's original idea, I do not know as much as you, but
under knitr's design, you can arrange code freely, since the code is
stored in a named list after the input document is parsed. You can
define code before using it, or use it before defining it (later); it
is indexed by the chunk label. Top-down or bottom-up, in whatever
order you want. And you are right; it requires a major rewrite, and
that is exactly what I tried to do. I appreciate your feedback because
I know you have very rich experience in reproducible research.
Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Mon, Jan 30, 2012 at 12:07 PM, Kevin R. Coombes
wrote:
> I prefer the code chunks myself.
>
> Function calls have overhead. In a bioinformatics world with large datasets
> and an R default that uses call-by-value rather than call-by-reference, the
> function calls may have a _lot_ of overhead. Writing the functions to make
> sure they use call-by-reference for the large objects instead has a
> different kind of overhead in the stress it puts on the writers and
> maintainers of code.
>
> But then, I'm old enough to have looked at some of Knuth's source code for
> TeX and read his book on Literate Programming, where the ideas of "weave"
> and "tangle" were created for exactly the kind of application that Terry
> asked about. Knuth's fundamental idea here is that the documentation
> (mainly the stuff processed through "weave") is created for humans, while
> the executable code (in Knuth's view, the stuff created by "tangle") is
> intended for computers. If you want people to understand the code, then you
> often want to use a top-down approach that outlines the structure -- code
> chunks with forward references work perfectly for this purpose.
>
> One of the difficulties in mapping Knuth's idea over to R and Sweave is that
> the operations of weave and tangle have gotten, well, tangled. Sweave does
> not just prepare the documentation; it also executes the code in order to
> put the results of the computation into the documentation. In order to get
> the forward references to work with Sweave, you would have to makes two
> passes through the file: one to make sure you know where each named chunk is
> and build a cross-reference table, and one to actually execute the code in
> the correct order. That would presumably also require a major rewrite of
> Sweave.
>
> The solution I use is to cheat and hide the chunks initially and reveal them
> later to get the output that want. This comes down to combining eval, echo,
> keep.source, and expand in the right combinations. Something like:
>
>
> % set up a prologue that contains the code chunks. Do not evaluate or
> display them.
> <>=
> # do something sensible. If multiple steps, define them above here
> # using the same idea.
> @
> % also define the other code chunks here
>
> \section{Start the First Section}
>
> The \texttt{coxme} function is defined as follows:
> <>=
>
> coxme <- function(formula, data, subset, blah blah ){
> <>
> <>
> <>
> <>
> }
> @
>
> Argument checking is important:
> <>=
> <>=
> @
> % Describe the other chunks here
>
>
>
>
> Kevin
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
