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