[Top][All Lists]

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

Re: [O] [0][babel][R] Undesired conversion of integers to floats in R co

From: Daniel Drake
Subject: Re: [O] [0][babel][R] Undesired conversion of integers to floats in R code block output
Date: Sat, 18 Feb 2012 23:02:43 -0800
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120217 Thunderbird/10.0.2

On 02/18/2012 08:23 AM, Eric Schulte wrote:
Daniel Drake<address@hidden>  writes:

Hi All,

I'm using R in org-mode/babel to analyze data from a psychological
study.  The subjects in this study are identified by nine digit integers
(e.g., 987654321) that I treat as strings (or factors) in my R data

Tables output by an R code block that contain these subject IDs are
not formatted properly: the subject IDs seem to be treated as numbers
and a decimal point and a trailing zero are appended.  For example,
what should be
|   subj.id |
| 987654321 |
|     subj.id |
| 987654321.0 |
(I've included real, self-contained code below.)

When I write the data frames directly to a file from within the R code
block (using a write.table function call that mimics the one in
ob-R.el), the integer IDs are preserved; but when code from ob-R.el
writes them out, the values get reformated as floats.

I've noticed that eight digit integers are not modified in the same
way, which makes me wonder if there is a 'digits' threshold I could
modify to prevent this from happening.

I've pretty much ruled out the possibility that this transformation
occurs in R; however I'm not proficient enough in elisp to follow the
operations that happen after the data frame is written to a file in
the org-babel-R-write-object-command.

Any pointers to help me figure this out would be very appreciated!
(I've seen this thread:
http://comments.gmane.org/gmane.emacs.orgmode/31373, but do not know
if the conversion to calc has been made already or if it is the source
of the problem.)

Hi Dan,

When I launch Emacs without any personal configuration (emacs -Q),
evaluate ob-R.el to add R support, and then execute your code blocks I
get the following behavior.

I would recommend installing the latest version of Org-mode from source
as that tends to fix many problems, and will at least ensure that we are
both working from the same code base moving forward.  See


Hi Eric,
First of all, thanks for your reply.

Just to be safe, I nuked my org-mode directory and re-cloned from the git repository: I'm now at release_7.8.03.386.g2239d (I was at release_7.8.03-351-g47eb3 previously). Is there a more recent version? I also removed the org directory that came with the packaged version of emacs, just in case.

I start emacs with the following options:
$ emacs -Q -eval '(setq load-path (cons "~/share/emacs/site-lisp/org-mode/lisp" load-path))' -eval "(require 'ob-R)" test.org

I get the same behavior as before. I was a little puzzled when I saw this happen, as I've been working on this study for over a year in org and it's the first time I've seen this behavior. I went back and tried previous versions (e.g., 7.4), and now I see the same thing.

I wonder if Arch (a rolling release linux distribution that tries to be close to the leading edge) has updated an underlying library that impacts the babel code in some odd way. (Granted, I don't see how this could be, as the emacs environment seems pretty well insulated from the underlying OS; PEBKAC just as likely.)

In any event, since you can't reproduce the behavior (thanks again for trying), I don't expect it's anything you can fix. Maybe it will show up in other distributions as they update to more current versions. In the mean time, I'll try to improve my elisp skills and figure out where the extraneous formatting occurs.


- GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of 2012-02-01 on shirley.hoetzel.info
- Org-mode version 7.8.03 (release_7.8.03.386.g2239d)

reply via email to

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