Michael Hannon <jm_han...@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