Re: Babel: communicating irregular data to R source-code block

[tsd@tsdye.com (Thomas S. Dye)]

Michael Hannon <jm_hannon@yahoo.com> writes:

> Greetings.  I'm sorry to belabor this, but I thought I had found a relatively
> clean way to pass a "ragged" table to an R source-code block.  Simple answer:
> add the "fill=TRUE" option to the read.table function.  Please see the
> appended for the log of an R session that does what I want.
>
> I then tried to do the same thing in an R source-code block:
>
>     #+RESULTS: pascals_triangle
>     | 1 |   |    |    |   |   |
>     | 1 | 1 |    |    |   |   |
>     | 1 | 2 |  1 |    |   |   |
>     | 1 | 3 |  3 |  1 |   |   |
>     | 1 | 4 |  6 |  4 | 1 |   |
>     | 1 | 5 | 10 | 10 | 5 | 1 |
>     
>     
>     #+NAME: sanity-check(sc_input=pascals_triangle)
>     #+BEGIN_SRC R
>     
>     pt <- read.table(sc_input, fill=TRUE)
>     rowSums(pt)
>     
>     #+END_SRC  
>
> Unfortunately, this still results in the "error" that the first line did not
> contain five elements:
>
> <<<<<<<<<<
>> Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings,
>> : 
>   line 1 did not have 5 elements
>
> Enter a frame number, or 0 to exit   
>
> 1: read.table("/tmp/babel-3780tje/R-import-37801if", header = FALSE, row.names
> = NULL, sep = "
> 2: scan(file = file, what = what, sep = sep, quote = quote, dec = dec, nmax =
> nrows, skip = 0,
>>>>>>>>>>>
>
> I.e.,it seems that Org is going to do its own "read.table" before even
> looking at the code in the source block.

Yes, I believe this happens when Org assigns values to R variables.

>
> Is there some way to get Org to use the "fill=TRUE" option on a case-by-case
> basis?

I don't think so.  The call to read.table in org-babel-R-assign-elisp
doesn't use the fill option:

        (format "%s <- read.table(\"%s\", header=%s, row.names=%s,
        sep=\"\\t\", as.is=TRUE)"

If I add fill=TRUE to that (on a git branch), then I get this:

#+RESULTS: pascals-triangle
| 1 |   |    |    |   |   |
| 1 | 1 |    |    |   |   |
| 1 | 2 |  1 |    |   |   |
| 1 | 3 |  3 |  1 |   |   |
| 1 | 4 |  6 |  4 | 1 |   |
| 1 | 5 | 10 | 10 | 5 | 1 |

#+NAME: sanity-check
#+HEADER: :var sc_input=pascals-triangle
#+BEGIN_SRC R
sc_input
#+END_SRC

#+RESULTS: sanity-check

| 1 | nil | nil | nil | nil |
| 1 |   1 | nil | nil | nil |
| 1 |   2 |   1 | nil | nil |
| 1 |   3 |   3 | 1   | nil |
| 1 |   4 |   6 | 4   | 1   |
| 1 |   5 |  10 | 10  | 5   |
| 1 | nil | nil | nil | nil |

which isn't correct, but gets past the scan error.

I'm in over my head here, but hope that my curiosity hasn't been too noisy.

All the best,
Tom
>
> Thanks.
>
> -- Mike
>
>
> Appendix: R code that correctly reads and processes a Pascal's triangle
> =======================================================================
>
>
>> system("cat pascal.dat")
> 1
> 1 1
> 1 2 1
> 1 3 3 1
> 1 4 6 4 1
>> 
>> x <- read.table("pascal.dat", fill=TRUE)
>> 
>> x
>   V1 V2 V3 V4 V5
> 1  1 NA NA NA NA
> 2  1  1 NA NA NA
> 3  1  2  1 NA NA
> 4  1  3  3  1 NA
> 5  1  4  6  4  1
>> 
>> y <- as.matrix(x)
>> 
>> y
>      V1 V2 V3 V4 V5
> [1,]  1 NA NA NA NA
> [2,]  1  1 NA NA NA
> [3,]  1  2  1 NA NA
> [4,]  1  3  3  1 NA
> [5,]  1  4  6  4  1
>> 
>> y[is.na(y)] <- 0
>> 
>> y
>      V1 V2 V3 V4 V5
> [1,]  1  0  0  0  0
> [2,]  1  1  0  0  0
> [3,]  1  2  1  0  0
> [4,]  1  3  3  1  0
> [5,]  1  4  6  4  1
>> 
>> dimnames(y)[[2]]=NULL  #### cosmetic change
>> 
>> y
>      [,1] [,2] [,3] [,4] [,5]
> [1,]    1    0    0    0    0
> [2,]    1    1    0    0    0
> [3,]    1    2    1    0    0
> [4,]    1    3    3    1    0
> [5,]    1    4    6    4    1
>> 
>
>

-- 
Thomas S. Dye
http://www.tsdye.com