From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Drake Subject: Re: [0][babel][R] Undesired conversion of integers to floats in R code block output Date: Sun, 19 Feb 2012 11:27:57 -0800 Message-ID: <4F414D3D.5010602@gmail.com> References: <4F3D53D6.40407@gmail.com> <87boowrtyv.fsf@gmx.com> <4F409E93.5010800@gmail.com> <878vjyg466.fsf@gmx.com> <4F413412.5050108@gmail.com> <4F413F30.60302@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:46461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzCSS-0004au-IB for emacs-orgmode@gnu.org; Sun, 19 Feb 2012 14:30:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzCSP-0002Qx-7A for emacs-orgmode@gnu.org; Sun, 19 Feb 2012 14:30:04 -0500 Received: from mail-gx0-f169.google.com ([209.85.161.169]:46160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzCSO-0002Qt-UQ for emacs-orgmode@gnu.org; Sun, 19 Feb 2012 14:30:01 -0500 Received: by ggnf1 with SMTP id f1so2880832ggn.0 for ; Sun, 19 Feb 2012 11:30:00 -0800 (PST) In-Reply-To: <4F413F30.60302@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: "emacs-orgmode@gnu.org" On 02/19/2012 10:28 AM, Daniel Drake wrote: > 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 > > > A further followup, at the risk of descending into minutia. The culprit seems to be the emacs function string-to-number. On my 32-bit Arch machine: (string-to-number "123456789"): 123456789 (#o726746425, #x75bcd15) (string-to-number "987654321"): 987654321.0 GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of 2012-02-01 on shirley.hoetzel.info On a 64-bit Ubuntu (11.10) machine: (string-to-number "123456789"): 123456789 (#o726746425, #x75bcd15) (string-to-number "987654321"): 987654321 (#o7267464261, #x3ade68b1) GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.5) of 2011-08-14 on allspice, modified by Debian The extra 3 bits required to represent the larger number apparently push my version of emacs into floating point territory.(log2(987654321)=29.87943; log2(123456789)=26.87943) Don't know if the difference is between emacs versions or 32- vs. 64-bit implementations, but I can probably figure it out from here. In any event, this doesn't seem to be an org-mode problem. Thanks again for all your help and for org-mode/babel in general! Dan >> >>>> >>>> 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) >>>> >>>> >