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

[Thomas S. Dye]

Michael Hannon <address@hidden> writes:

> On Wednesday, April 25, 2012 at 4:52 PM Thomas S. Dye wrote:
>
>>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
>>>
>>>
>>Aloha Mike,
>>
>>Eric Schulte has pushed up some patches designed to make R source block
>>variables accept irregular data.  So, with pascals-triangle(8), for
>>instance, one gets a potentially useful dataframe in R:
>>
>>#+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 | nil | nil | nil |
>>| 1 |   1 | nil | nil | nil | nil | nil | nil | nil |
>>| 1 |   2 |   1 | nil | nil | nil | nil | nil | nil |
>>| 1 |   3 |   3 |   1 | nil | nil | nil | nil | nil |
>>| 1 |   4 |   6 |   4 |   1 | nil | nil | nil | nil |
>>| 1 |   5 |  10 |  10 |   5 | 1   | nil | nil | nil |
>>| 1 |   6 |  15 |  20 |  15 | 6   | 1   | nil | nil |
>>| 1 |   7 |  21 |  35 |  35 | 21  | 7   | 1   | nil |
>>| 1 |   8 |  28 |  56 |  70 | 56  | 28  | 8   | 1   |
>>
>>Could you pull the development version of Org mode and see if this
>>solves your problem?
>
> Well, NOW you've done it!  Just when I thought I could beg off on this talk,
> it all seems to be working ;-)  Thanks, Tom and Eric.
>
> I've appended a sample output, just FYI.  I also tried it for n=7 and got the
> correct results.  Magic!
>
> As an aside, the rows of the Pascal Triangle should sum to 2^n, which they do
> in my test cases.  I haven't yet implemented Eric's (much sexier)
> "sum(sub-diagonal-elements) == Fibonacci nos." test, but I'll look into it.
>
> Thanks again,
>
> -- Mike

Good news.  Please consider sharing your seminar talk on Worg, if you
think it might be appropriate.

All the best,
Tom

>
> #############################################################
>
> Org-mode version 7.8.09 (release_7.8.09-390-gfb7ebd @
> /usr/local/emacs.d/org-mode/org-devel/org-mode/lisp/org-install.el)
>
> -----
>
> #+PROPERTY: session *R*
> * verify PT
>
> #+name: pascals_triangle
> #+begin_src python :var n=5 :exports none :results value
> def pascals_triangle(n):
>     if n == 0:
>         return [[1]]
>     prev_triangle = pascals_triangle(n-1)
>     prev_row = prev_triangle[n-1]
>     this_row = map(sum, zip([0] + prev_row, prev_row + [0]))
>     return prev_triangle + [this_row]
>
> pascals_triangle(n)
> #+end_src
>
> #+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 :fill yes :results output
>   
>   pt <- sc_input
>   pt[is.na(pt)] <- 0
>   rowSums(pt)
>   
>   
> #+END_SRC  
>
> #+RESULTS: sanity-check
> : [1]  1  2  4  8 16 32
>
>

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