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