From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Bill Schottstaedt Newsgroups: gmane.lisp.guile.devel Subject: Re: ratio implementation Date: Tue, 16 Sep 2003 04:39:55 -0700 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <3F66F68B.3070100@ccrma.stanford.edu> References: <3F250809.9030108@ccrma.stanford.edu> <87smmyibk7.fsf@zagadka.ping.de> <3F6637EC.7010004@dirk-herrmanns-seiten.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1063713458 26313 80.91.224.253 (16 Sep 2003 11:57:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 16 Sep 2003 11:57:38 +0000 (UTC) Cc: guile-devel@gnu.org, Marius Vollmer Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Sep 16 13:57:36 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 19zESe-000108-00 for ; Tue, 16 Sep 2003 13:57:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 19zESF-00023l-RM for guile-devel@m.gmane.org; Tue, 16 Sep 2003 07:57:11 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 19zER4-0001ZJ-Ih for guile-devel@gnu.org; Tue, 16 Sep 2003 07:55:58 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 19zEQd-0001L7-Mi for guile-devel@gnu.org; Tue, 16 Sep 2003 07:55:32 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.22) id 19zENq-0000O7-IM for guile-devel@gnu.org; Tue, 16 Sep 2003 07:52:38 -0400 Original-Received: from [171.67.16.35] (helo=smtp8.Stanford.EDU) by mx20.gnu.org with esmtp (Exim 4.22) id 19zEBr-0006hT-JJ for guile-devel@gnu.org; Tue, 16 Sep 2003 07:40:15 -0400 Original-Received: from cm-mail.stanford.edu (cm-mail.Stanford.EDU [171.64.197.135]) by smtp8.Stanford.EDU (8.12.9/8.12.9) with ESMTP id h8GBdvdr000636; Tue, 16 Sep 2003 04:39:58 -0700 (PDT) Original-Received: from cmn13.stanford.edu (cmn13.stanford.edu [171.64.197.162]) by cm-mail.stanford.edu (8.11.6/8.11.6) with ESMTP id h8GBduO12034; Tue, 16 Sep 2003 04:39:56 -0700 Original-Received: from ccrma.stanford.edu (localhost [127.0.0.1]) by cmn13.stanford.edu (8.12.8/8.12.5) with ESMTP id h8GBdtuh006323; Tue, 16 Sep 2003 04:39:56 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en Original-To: Dirk Herrmann In-Reply-To: <3F6637EC.7010004@dirk-herrmanns-seiten.de> 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:2804 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2804 > That is, instead of using "long", I'd say we simply use "SCM" and > instead of "+", "==", etc, we use use "scm_sum", "scm_num_eq_p", etc. > Also, instead of mallocing scm_t_ratio, we can use double cells, which > should be more efficient. > > Any takers? Looks straightforward, but I may not get around to it right away. Should I wait for Dirk's type-related changes? Also, I haven't looked closely at double cells, though I assume (from a glance at the scm_t_double stuff) that I can include my "reduce" flag as well as the numerator and denominator. The point being to reduce calls on gcd as much as possible (this being Guile's integer divide, there's some desire to keep it from crawling). But, it's an optional optimization. > (Also I didn't really check whether your rationals behave like R5RS > demands it. Did you? We should be sure to follow R5RS.) Yes, I think it follows R5RS. See test-ratios.scm for some tests. I could make these fit into 'make check'. > A ratio is exact, while a real is not. Thus, I'd say that ratio? is > not really necessary. There should be no reason to add anything eyond > R5RS for ratios. Ok -- "exact?" used to return #f for 3/4 -- hence the confusion. >> An alternative would be to make "rational?" rational. > That would violate R5RS, wouldn't it? I don't think so. You are allowed to make rational? be the same as real?, but you can also distinguish them. My druthers would be for rational? to return #t for a ratio, #f for a float. Why have it at all if it is just a synonym for "real?"? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel