From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: Tangling with variables in R Date: Wed, 11 Jun 2014 22:36:23 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuqCF-0004HY-6t for emacs-orgmode@gnu.org; Wed, 11 Jun 2014 17:36:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuqCA-0007zm-1t for emacs-orgmode@gnu.org; Wed, 11 Jun 2014 17:36:39 -0400 Received: from plane.gmane.org ([80.91.229.3]:57442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuqC9-0007zR-N5 for emacs-orgmode@gnu.org; Wed, 11 Jun 2014 17:36:33 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WuqC7-0004gJ-QN for emacs-orgmode@gnu.org; Wed, 11 Jun 2014 23:36:31 +0200 Received: from cpc33-cmbg15-2-0-cust4.5-4.cable.virginm.net ([81.102.136.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Jun 2014 23:36:31 +0200 Received: from andreas.leha by cpc33-cmbg15-2-0-cust4.5-4.cable.virginm.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Jun 2014 23:36:31 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hi Rainer, Rainer M Krug 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