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:20:46 +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> <3F8D4456.40801@ccrma> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1066386449 12444 80.91.224.253 (17 Oct 2003 10:27:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2003 10:27:29 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Oct 17 12:27:26 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 1AARpO-0000CL-00 for ; Fri, 17 Oct 2003 12:27:26 +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 1AARnY-0004zF-TQ for guile-devel@m.gmane.org; Fri, 17 Oct 2003 06:25:32 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AARjV-0003vg-J1 for guile-devel@gnu.org; Fri, 17 Oct 2003 06:21:21 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AARiy-0003hL-Bu for guile-devel@gnu.org; Fri, 17 Oct 2003 06:21:19 -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 1AARix-0003gr-MT for guile-devel@gnu.org; Fri, 17 Oct 2003 06:20:47 -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 CF7B510685; Fri, 17 Oct 2003 12:20:46 +0200 (CEST) Original-Received: by troy.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id 46C4FB940; Fri, 17 Oct 2003 12:20:46 +0200 (CEST) Original-To: Bill Schottstaedt In-Reply-To: <3F8D4456.40801@ccrma> (Bill Schottstaedt's message of "Wed, 15 Oct 2003 05:57:58 -0700") 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:2893 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2893 Bill Schottstaedt writes: > > With your new files, I now get > > guile> (inexact->exact 123456789123456789.0) > > 0 > > I noticed this, but wasn't sure how to proceed; > in the previous guile, you'd get (in a sense) equally > bogus results: > > guile> (inexact->exact 17452826108659293487.0) > 17452826108659294208 Hmm, I'd say that this is not nearly as bogus. It is not very accurate (since doubles do not have that much precision), but much better than zero. (Did I use 'accurate' and 'precise' correctly? :) > I wasn't even sure whether you wanted inexact->exact to > be changed -- I left the old code in place. Yes, it needs to be changed. People who have assumed that inexact->exact always returns an integer need to think again (I'm afraid I'm one of them...). > I wrote a gmp version of the continued fraction code about 10 years > ago -- I think I can still find it. Hmm, what about a SCM version of the code? I'm about to write such a thing, but I first needed a proper scm_floor... > > guile> (define pi (* 2 (acos 0))) > > guile> (- (inexact->exact pi) pi) > > 3.31628058347633e-10 > > Shouldn't we be able to do better than this? > > I think so; but in the current version, I'm setting the > minimum error to 1/INT_MAX, which looks like it's in the > ballpark of e-10. The SCM version of rationalize can work to arbitrary error margins (hopefully), by using generic SCM arithmetic instead of the longs and doubles that your version uses. That will make rationalize a bit slower, but hey. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel