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

[Thomas S. Dye]

Michael Hannon <address@hidden> writes:

> On Monday, April 23, 2012 at 11:44 PM Thomas S. Dye wrote:
> .
> .
> .
>> 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.
> .
> .
> .
>
> Thanks, Tom.  I had just run across this myself. I guess I need to walk a mile
> in somebody's moccasins before complaining, but this behavior on the part of R
> seems totally stupid to me.
>
> I'm going to have to mull this over some more.
>
> -- Mike
>
>
Yes, please do. I'm not a programmer, and often get things wrong, but I
trust you'll help rein me in if I get off on a tangent. 

It would be good if this limitation in ob-R were eliminated.  The way I
see it, ob-R is designed to handle a subset of the expected input.  It
coerces a variable into a tsv table, then reads it into R, expecting all
cells are filled.  At the same time, other babel modules are free to
export structures (in the Pascal's triangle example, a list of lists)
that orgtbl-to-tsv interprets as a table with empty cells.  It would be
nice if ob-R could be made to read all the tables that orgtbl-to-tsv is
able to create.

All the best,
Tom 

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