On Wednesday, April 25, 2012 at 4:52 PM Thomas S. Dye wrote:
>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
>>
>>
>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
#############################################################
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
