Re: [0][babel][R] Undesired conversion of integers to floats in R code block output

[Daniel Drake <silophophe@gmail.com>]

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