From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles C. Berry" Subject: Re: Straight recursive fact prints in floating-point in org-babel but not in REPL Date: Sun, 6 Dec 2015 09:44:58 -0800 Message-ID: References: <87r3j0uv5u.fsf@pierrot.dokosmarshall.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5dMw-0000D1-RT for emacs-orgmode@gnu.org; Sun, 06 Dec 2015 12:45:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a5dMr-0004xT-Ee for emacs-orgmode@gnu.org; Sun, 06 Dec 2015 12:45:06 -0500 Received: from iport-acv1-out.ucsd.edu ([132.239.0.176]:49620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5dMr-0004xM-6D for emacs-orgmode@gnu.org; Sun, 06 Dec 2015 12:45:01 -0500 In-Reply-To: <87r3j0uv5u.fsf@pierrot.dokosmarshall.org> 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: Nick Dokos Cc: emacs-orgmode@gnu.org 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/