[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (rele

From: Titus von der Malsburg
Subject: Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
Date: Fri, 29 May 2015 11:54:21 -0700

On 2015-05-29 Fri 11:09, Charles C. Berry wrote:
> On Fri, 29 May 2015, Nicolas Goaziou wrote:
>> Titus von der Malsburg <address@hidden> writes:
>>> On 2015-05-24 Sun 10:09, Thomas S. Dye wrote:
>>>> Titus von der Malsburg <address@hidden> writes:
>>>>> On 2015-05-24 Sun 08:36, Thomas S. Dye wrote:
>>>>>> Titus von der Malsburg <address@hidden> writes:
>>>>>>>> You got the result of rownames(x), which is expected.  The table you
>>>>>>>> expect is given by the following code:
>>>>>>> Ah, I see, thanks.  Although the results is still somewhat
>>>>>>> unexpected.  c("One:", "Two:") doesn’t have rownames and colnames.  So
>>>>>>> org apparently made them up when generating the table.
>>>>>> Also expected due to :rownames yes :colnames yes.  Without those two
>>>>>> header arguments:
>>>>> Consider this example:
>>>>> #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes
>>>>>   v <- c("a", "b")
>>>>> #+END_SRC
>>>>> #+RESULTS:
>>>>> |   | x |
>>>>> |---+---|
>>>>> | 1 | a |
>>>>> | 2 | b |
>>>>> Where is the “x” coming from?  In R, colnames(v) gives me NULL.
>>>> rownames(v) is also NULL.
>>>> You are asking Org mode to produce a table with row and column names
>>>> from a vector, which lacks rows and columns.  What behavior do you
>>>> expect?
>>> Almost anything is better than Org showing me values that do not exist
>>> in the original data.  Empty cells for row and columns names are
>>> probably the best solution because that would be faithful to the data
>>> and to the settings (:rownames yes :colnames yes).
>> AFAICT, the "x" comes from R, not Org. It could also come from the way
>> Org calls R, but I don't know enough of the latter to tell.
> In particular, `org-babel-R-write-object-command' contains an R
> function that processes the object for `:results value'. The guts of
> it is a call to write.table(). Here is an example:
> #+NAME: show write.table
> #+BEGIN_SRC R :results output
>    write.table(c("a","b"))
> #+RESULTS: show write.table
> : "x"
> : "1" "a"
> : "2" "b"
> The difficulty is that write.table() coerces its first argument to a 
> `data.frame', whence the odd seeming row/column labels.
> Making the R code in `org-babel-R-write-object-command' smart enough
> to do what the OP wants without breaking stuff might be possible if 
> anyone wants to do the work.

Thanks for the pointer, Charles.  If this is standard behaviour in R,
I’m actually fine with it.  It just wasn’t clear that write.table is
used for making tables.

I would add a note about this in the documentation but, correct
me if I’m wrong, the whole “:results table“-thing isn’t yet described in
the documentation.  Is that correct?


> However, IMO `:results output' is the way to go for such cases. There are 
> plenty of tools in R for formatting output and the user will have better 
> control over what is produced.

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]