From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: ratio implementation Date: Fri, 17 Oct 2003 12:09:02 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <3F250809.9030108@ccrma.stanford.edu> <87smmyibk7.fsf@zagadka.ping.de> <3F6637EC.7010004@dirk-herrmanns-seiten.de> <3F66F68B.3070100@ccrma.stanford.edu> <3F6A1F1A.8000507@dirk-herrmanns-seiten.de> <87pth9cbmt.fsf@zagadka.ping.de> <3F8A853D.1020708@ccrma> <87oewjcrwq.fsf@zip.com.au> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1066385550 10914 80.91.224.253 (17 Oct 2003 10:12:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2003 10:12:30 +0000 (UTC) Cc: Bill Schottstaedt Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Oct 17 12:12:28 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AARat-00082M-00 for ; Fri, 17 Oct 2003 12:12:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AARYJ-0008K3-NX for guile-devel@m.gmane.org; Fri, 17 Oct 2003 06:09:47 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AARYC-0008Jk-Uy for guile-devel@gnu.org; Fri, 17 Oct 2003 06:09:40 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AARXg-00085r-Rv for guile-devel@gnu.org; Fri, 17 Oct 2003 06:09:39 -0400 Original-Received: from [129.217.163.1] (helo=mail.dt.e-technik.uni-dortmund.de) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AARXg-000858-7T for guile-devel@gnu.org; Fri, 17 Oct 2003 06:09:08 -0400 Original-Received: from troy.dt.e-technik.uni-dortmund.de (troy.dt.e-technik.uni-dortmund.de [129.217.163.17]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 24551BC6D; Fri, 17 Oct 2003 12:09:04 +0200 (CEST) Original-Received: by troy.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id 3A90EB9B4; Fri, 17 Oct 2003 12:09:02 +0200 (CEST) Original-To: guile-devel@gnu.org In-Reply-To: <87oewjcrwq.fsf@zip.com.au> (Kevin Ryde's message of "Wed, 15 Oct 2003 09:37:25 +1000") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2892 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2892 Kevin Ryde writes: > Marius Vollmer writes: >> >> I don't have the details ready yet, but I think I'll try to come up >> with code for this... (when it isn't already in GMP). > > gmp has an mpq_set_d, which does what you imagine, extract the bits to > make a binary fraction. The actual implementation is uglified by the > details of gmp internals though. Yes, that's what I was looking for. I now have in scm_inexact_to_exact else if (SCM_REALP (z)) { mpq_t frac; SCM q; mpq_init (frac); mpq_set_d (frac, SCM_REAL_VALUE (z)); q = scm_make_ratio (scm_i_mpz2num (mpq_numref (frac)), scm_i_mpz2num (mpq_denref (frac))); mpq_clear (frac); return q; } using the helper static SCM_C_INLINE_KEYWORD SCM scm_i_mpz2num (mpz_t b) { /* convert a mpz number to a SCM number. */ if (mpz_fits_slong_p (b)) { long val = mpz_get_si (b); if (SCM_FIXABLE (val)) return SCM_MAKINUM (val); } { SCM z = scm_double_cell (scm_tc16_big, 0, 0, 0); mpz_init_set (SCM_I_BIG_MPZ (z), b); return z; } } Kevin, does this look OK from a GMP point of view? I.e., no memory leaks, etc? That code gives perfect accuracy but that can be strange as well: guile> (exact->inexact 1/1000) 0.001 guile> (inexact->exact (exact->inexact 1/1000)) 1152921504606847/1152921504606846976 guile> (rationalize (exact->inexact 1/1000) 1e-16) 1/1000 The above behavior of inexact->exact better fits R5RS, I'd say, since R5RS calls for the _closest_ representable exact number, not for the simplest, as with rationalize. So I'm inclined to use it intead of rationalize. Ok? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel