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

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

Eric Schulte <eric.schulte@gmx.com> writes:

>> 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.
>>
>
> Hmm, this happens with my patch applied as well.  It seems to me this
> *must* be an R error.  The raw textual data pre-import has no such wrap.
>
> 1
> 1	1
> 1	2	1
> 1	3	3	1
> 1	4	6	4	1
> 1	5	10	10	5	1
>
> Why would R intentionally wrap a table at an arbitrary column?
>
>>
>> I'm in over my head here, but hope that my curiosity hasn't been too
>> noisy.
>>
>
> Me too.  Unless someone who is familiar with the motivations and design
> decisions behind R's read.table function, I'm inclined to leave the
> current Org-mode code as is.
>
> Thanks,

The documentation of read.table has this:

The number of data columns is determined by looking at the first five
lines of input (or the whole file if it has less than five lines), or
from the length of col.names if it is specified and is longer. This
could conceivably be wrong if fill or blank.lines.skip are true, so
specify col.names if necessary (as in the ‘Examples’).

The example is this:

read.csv(tf, fill = TRUE, header = FALSE,
         col.names = paste("V", seq_len(ncol), sep = ""))

where read.csv is a synonym of read.table with preset arguments.

This explains why the sixth line wraps.

Unfortunately, ncol passed to seq_len doesn't cooperate.  I can hard
code the read.table call this way:

        (format "%s <- read.table(\"%s\", header=%s, row.names=%s, sep=\"\\t\", as.is=TRUE, fill=TRUE, col.names = paste(\"V\", seq_len(6), sep = \"\"))"

This works for the example with six columns:

#+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 | nil |
| 1 |   1 | nil | nil | nil | nil |
| 1 |   2 |   1 | nil | nil | nil |
| 1 |   3 |   3 |   1 | nil | nil |
| 1 |   4 |   6 |   4 | 1   | nil |
| 1 |   5 |  10 |  10 | 5   | 1   |

I think that seq_len(%s) passed the number of columns in the orgtbl-tsv
table might do the trick, but I don't know how to do this, or if this
information is available.  I also don't have any idea what these changes
might do to regular tables.

All the best,
Tom
 
-- 
Thomas S. Dye
http://www.tsdye.com