emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: tsd@tsdye.com (Thomas S. Dye)
To: Eric Schulte <eric.schulte@gmx.com>
Cc: Michael Hannon <jm_hannon@yahoo.com>,
	Org-Mode List <emacs-orgmode@gnu.org>
Subject: Re: Babel: communicating irregular data to R source-code block
Date: Mon, 23 Apr 2012 20:44:55 -1000	[thread overview]
Message-ID: <m1fwbty6fs.fsf@tsdye.com> (raw)
In-Reply-To: <87aa22t5vn.fsf@gmx.com> (Eric Schulte's message of "Mon, 23 Apr 2012 18:55:56 -0400")

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

  reply	other threads:[~2012-04-24  6:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-21 20:17 Babel: communicating irregular data to R source-code block Michael Hannon
2012-04-22  0:44 ` Thomas S. Dye
2012-04-22 15:58   ` Eric Schulte
2012-04-23 16:46     ` Thomas S. Dye
2012-04-23 15:41       ` Eric Schulte
2012-04-23 19:17         ` Thomas S. Dye
2012-04-23 22:24     ` Michael Hannon
2012-04-23 21:05       ` Eric Schulte
2012-04-24  0:23       ` Thomas S. Dye
2012-04-23 22:55         ` Eric Schulte
2012-04-24  6:44           ` Thomas S. Dye [this message]
2012-04-24  7:07             ` Michael Hannon
2012-04-24 17:18               ` Thomas S. Dye
2012-04-24 19:23                 ` Thomas S. Dye
2012-04-25 23:52               ` Thomas S. Dye
2012-04-26  2:06                 ` Michael Hannon
2012-04-26  6:34                   ` Thomas S. Dye

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1fwbty6fs.fsf@tsdye.com \
    --to=tsd@tsdye.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=eric.schulte@gmx.com \
    --cc=jm_hannon@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).