Straight recursive fact prints in floating-point in org-babel but not in REPL

Straight recursive fact prints in floating-point in org-babel but not in REPL

[Brian Beckman]

Org-babel seems to print SLIME / SBCL bignums as floating point, at least in
this gist (please see
https://gist.github.com/rebcabin/f73cecd3c9b7da6218e9).  I'd like to be able
to control whether bignums are printed out in full.  Any advice for me?

Re: Straight recursive fact prints in floating-point in org-babel but not in REPL

[Nick Dokos]

Brian Beckman <bc.beckman@gmail.com> writes:

> Org-babel seems to print SLIME / SBCL bignums as floating point, at least in
> this gist (please see
> https://gist.github.com/rebcabin/f73cecd3c9b7da6218e9).  I'd like to be able
> to control whether bignums are printed out in full.  Any advice for me?
>

I think this happens because babel turns result strings into elisp
objects, using (read ...).

This has two consequences: the string has to be legal emacs-lisp (that
causes problems with e.g. scheme evaluators which return things like #t
and #f on which the elisp reader chokes; note also the conversion of
lisp-vector-to-list in ob-lisp.el which is done to avoid similar
problems); it also does violence to some strings as you have observed -
e.g. try

(read "123456789123456789123456789")
1.2345678912345679e+26

I'm not sure whether the (read ...) is required in order for babel
to work correctly, or whether it is a bug. I've wanted to look into
this for a while now (ever since Lawrence Bottorff reported the #t
problem with scheme), but I have not been able to find any time to
do so.

-- 
Nick

Re: Straight recursive fact prints in floating-point in org-babel but not in REPL

[Charles C. Berry]

On Sat, 5 Dec 2015, Nick Dokos wrote:

> Brian Beckman <bc.beckman@gmail.com> writes:
>
>> Org-babel seems to print SLIME / SBCL bignums as floating point, at least in
>> this gist (please see
>> https://gist.github.com/rebcabin/f73cecd3c9b7da6218e9).  I'd like to be able
>> to control whether bignums are printed out in full.  Any advice for me?
>>

You can convert them to strings yourself and get ahead of the (read 
...) issue Nick explains.


--8<---------------cut here---------------start------------->8---
#+BEGIN_SRC emacs-lisp
   (defun fact (n)
     (if (= 0 n)
 	1
       (* n (fact (- n 1.0)))))
   (format "%.0f" (fact 60))
#+END_SRC

#+RESULTS:
: 
8320987112741391580056396102959641077457945541076708813599085350531187384917164032
--8<---------------cut here---------------end--------------->8---

HTH,

Chuck

>
> I think this happens because babel turns result strings into elisp
> objects, using (read ...).
>
> This has two consequences: the string has to be legal emacs-lisp (that
> causes problems with e.g. scheme evaluators which return things like #t
> and #f on which the elisp reader chokes; note also the conversion of
> lisp-vector-to-list in ob-lisp.el which is done to avoid similar
> problems); it also does violence to some strings as you have observed -
> e.g. try
>
> (read "123456789123456789123456789")
> 1.2345678912345679e+26
>
> I'm not sure whether the (read ...) is required in order for babel
> to work correctly, or whether it is a bug. I've wanted to look into
> this for a while now (ever since Lawrence Bottorff reported the #t
> problem with scheme), but I have not been able to find any time to
> do so.
>
> -- 
> Nick
>
>
>

Charles C. Berry                 Dept of Family Medicine & Public Health
cberry at ucsd edu               UC San Diego / La Jolla, CA 92093-0901
http://famprevmed.ucsd.edu/faculty/cberry/