emacs-orgmode
[Top][All Lists]
Advanced

[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: Sun, 19 Feb 2012 10:28:00 -0800
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120217 Thunderbird/10.0.2

On 02/19/2012 09:40 AM, Daniel Drake wrote:
On 02/19/2012 08:48 AM, Eric Schulte wrote:
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.


This sounds just like my setup. I get the following from `org-version'
which should be equivalent.

Org-mode version 7.8.03 (release_7.8.03.419.gdeb6e)


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 just did the same using the following command line to launch Emacs,
and I still get no decimal place in my results.

$ emacs -Q -eval '(setq laod-path (cons "~/.emacs.d/src/org/lisp/"
load-path))' -eval "(require 'ob-R)" /tmp/dan.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.)


I doubt this is the case. I also use Arch (just ran pacman -Syu this
morning) so we likely have the largely same underlying versions of
libraries installed. Maybe the issue could lay somewhere in your R
config?

Sorry I can't be of more help.

Best,


At first I thought it was R as well, but the fact that there is no
decimal point in the output file plus the fact that (outside of emacs) I
can use read.table to pull in the table and the result has no decimal
formatting makes me think otherwise. That you're running the same setup
as me, though, gives me hope. I can backup, re-install Arch, and see if
the problem goes away.

Thanks for your help. I'm not certain when I'll have time to try this,
but I'll follow up on this thread when I do.

Best,
Dan

I'm following up on my last post, just to have it in the record: I've boiled down the behavior to these two examples: output the results by value vs output. R seems not to have anything to do with it. Somehow the "by value" code is intervening. I'll try to debug.

command line:
$ emacs -Q -eval '(setq load-path (cons "~/share/emacs/site-lisp/org-mode/lisp" load-path))' -eval "(require 'ob-sh)" test.org

In the buffer:
*** by output
#+name: by-output
#+begin_src sh  :results output
  echo 987654321
#+end_src

#+RESULTS: by-output
: 987654321

*** by value
#+name: by-value
#+begin_src sh  :results value
  echo 987654321
#+end_src

#+RESULTS: by-value
: 987654321.0





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.

Best,
Dan

- 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]