emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Tangling with variables in R


From: Andreas Leha
Subject: Re: [O] Tangling with variables in R
Date: Wed, 11 Jun 2014 22:36:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (darwin)

Hi Rainer,

Rainer M Krug <address@hidden> writes:

> Hi
>
> I just realized (again) that tangling with variables in R contains many
> particularities.
>
> 1) it only works with non-tables, i.e. single values.
>
> When defining the following variables:
>
> #+NAME: YEARS
> |   | year          |
> |---+---------------|
> | 1 | 1990          |
> | 2 | 2000          |
> #+PROPERTY: var+ YEARS=YEARS
> #+PROPERTY: var+ PRESENT=2008
>
>
> I get the following code in the tangled .R file:
>
> ,----
> | YEARS <- 
> read.table("/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-97151aBD/R-import-97151vpn",
> |                       header=TRUE,
> |                       row.names=1,
> |                       sep="\t",
> |                       as.is=TRUE)
> | PRESENT <- 2008
> `----
>
> Variable transfer from tables does not work, as it is based on a
> temporary file, which is not easy to distribute together with the
> tangled.R file and requires manual work as the path will be different.
>
> I consider this as a bug which should be fixed.

Me too, see http://thread.gmane.org/gmane.emacs.orgmode/51067


>
> 2) With regards to variables which are defined non-file wide, (i.e. in
> properties in a subtree and variables defined per code block and
> function call), these are set when they occur in the tangled code, but
> they are not unset *for the next code block* or *for R code in the next
> subtree* (I hope you know what I mean). They are therefore similar to
> the use of a session header argument instead of non-session evaluation
> of the code.
>
> This is a (conceptually) a more complex issue, and requires some initial
> thought on how this should be dealt with and how the tangled code should
> relate to the executed code.
>
> - Should the tangled .R file result in the same output as the execution in
> the org file, i.e. an accompanying .R file to a exported pdf, so that
> the .R file can be used to reproduce the graphs and analysis in the .pdf
> exported from the .org? or
>
> - Is tangling a completely thing to execution, and the resulting R code
> in the .R file is not expected to reproduce the results in the org file?
>
> - Finally, does tangling with variables makes sense?
>
> My opinions are 
>
> a) *All* variables should be transferred to the .R file. This can be
> already disabled via the :no-expand header argument. Unfortunately, this
> is combined with noweb expansion, and it might be useful to split these
> two, i.e. to be able to only disable variable expansion but to keep
> noweb (I don't use noweb so far, so it is not a problem to me as it is
> now).
>
> b) The variable assignments should be per code block / function call. So
> a tangled block should look as follow:
>
> #+NAME: YEARS
> |   | year          |
> |---+---------------|
> | 1 | 1990          |
> | 2 | 2000          |
> #+PROPERTY: var+ YEARS=YEARS
> #+PROPERTY: var+ PRESENT=2008
>
> #+begin_src R
> x <- 4
> cat(x^2)
> #+end_src
>
> should result in something like the following:
>
> ,----
> | ## # Set the variables
> | YEARS <- TRANSFER_TABLE()
> | PRESENT <- TRANSFER_VALUE()
> | ## Here begins the real code
> | x <- 4
> | cat(x^2)
> | ## # Unset all variables previously set
> `----
>
> but I prefer the following approach, as the result would be very
> similar, only that the variables are still present afterwards which
> would make debugging easier:
>
> ,----
> | ## # Unset all variables previously set
> | ## # Set the variables
> | YEARS <- TRANSFER_TABLE()
> | PRESENT <- TRANSFER_VALUE()
> | ## Here begins the real code
> | x <- 4
> | cat(x^2)
> `----
>
> This is effectively already implemented by using R environments. See [1]
> and particularly [2] and [3] for how it is implemented. This does not
> yet address the concern about the transfer of tables, but I will look at
> this.

These are good thoughts!

For the general question on whether tangling should directly reflect
weaving, there was a long (and fruitless) discussion or R-devel lately.
See http://thread.gmane.org/gmane.comp.lang.r.devel/36031 and maybe
http://thread.gmane.org/gmane.comp.lang.r.devel/36031/focus=36075 where
Yihui states that it is very hard to tangle code that produces the
same result as weaving.  This might actually be easier in org than in
Sweave/knitr, but still the org setup will have a big impact, that would
be hard to replicate in the tangled R code.

Setting aside the general question:
In my opinion, it should definitely be possible to tangle with
variables.  I think the approach of the environments to address (2) is a
good one.



>
> Apologies for a long post, but I would like to know which direction of
> the tangling / variable transfer from org to R should take - I don't
> want to spend a lot of time solving a problem which does not really
> exist.
>
> So - any comments? Suggestions?
>

See above.  And thanks for your work on ob-R!  Keep it up!

> Thanks,
>
> Rainer
>
> Footnotes: 
> [1]  https://github.com/rkrug/orgmode-dev
>
> [2]  https://github.com/rkrug/orgmode-dev/blob/R-env/lisp/ob-R.el
>
> [3]  https://github.com/rkrug/orgmode-dev/blob/R-env/etc/R/org_functions.R


Best,
Andreas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]