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

2015-12-04 Thread 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: [O] Straight recursive fact prints in floating-point in org-babel but not in REPL

2015-12-05 Thread Nick Dokos
Brian Beckman  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: [O] Straight recursive fact prints in floating-point in org-babel but not in REPL

2015-12-06 Thread Charles C. Berry

On Sat, 5 Dec 2015, Nick Dokos wrote:


Brian Beckman  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/