From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: ratio implementation Date: Thu, 18 Sep 2003 23:09:46 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <3F6A1F1A.8000507@dirk-herrmanns-seiten.de> References: <3F250809.9030108@ccrma.stanford.edu> <87smmyibk7.fsf@zagadka.ping.de> <3F6637EC.7010004@dirk-herrmanns-seiten.de> <3F66F68B.3070100@ccrma.stanford.edu> 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 1063920255 8805 80.91.224.253 (18 Sep 2003 21:24:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 18 Sep 2003 21:24:15 +0000 (UTC) Cc: guile-devel@gnu.org, Marius Vollmer Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Sep 18 23:24:13 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 1A06G4-00055w-00 for ; Thu, 18 Sep 2003 23:24:12 +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 1A06FR-0007wm-HE for guile-devel@m.gmane.org; Thu, 18 Sep 2003 17:23:33 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 1A06F7-0007vl-Vf for guile-devel@gnu.org; Thu, 18 Sep 2003 17:23:13 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 1A06F5-0007v8-VI for guile-devel@gnu.org; Thu, 18 Sep 2003 17:23:12 -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 1A06F5-0007sP-NW for guile-devel@gnu.org; Thu, 18 Sep 2003 17:23:11 -0400 Original-Received: from [212.227.126.184] (helo=moutng.kundenserver.de) by mx20.gnu.org with esmtp (Exim 4.22) id 1A06DN-0006f0-Os for guile-devel@gnu.org; Thu, 18 Sep 2003 17:21:25 -0400 Original-Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A06DJ-000563-00; Thu, 18 Sep 2003 23:21:21 +0200 Original-Received: from [80.131.37.203] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1A06DI-000371-00; Thu, 18 Sep 2003 23:21:21 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: de, en Original-To: Bill Schottstaedt In-Reply-To: <3F66F68B.3070100@ccrma.stanford.edu> 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:2807 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2807 Bill Schottstaedt wrote: > Looks straightforward, but I may not get around to it right away. > Should I wait for Dirk's type-related changes? Just for your information: I have submitted a patch which does the first part: Introducing scm_tc7_number and turning bignums, reals and complex numbers from smobs into subtypes of scm_tc7_number. The patch, however, is quite simplistic and does not yet optimize the way the subtypes of scm_tc7_number are allocated. It should nevertheless provide the type-system infrastructure for easy integration of the fraction type. > > 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?"? Just a side note: We should in guile distinguish between the internal representation of values, and their mathematical meaning. For example, fixnums and bignums are two representation of integer types. They should, however, also report #t when queried about being rational, real or complex, since they are elements of all these sets. When introducing exact rationals, which are represented internally as a pair of two exact integer values, we should not name them rationals, but, for example, fractions. The reason I mention this is that I want to avoid a macro SCM_RATIONAL_P to be introduced: The meaning of such a macro would not be clear, since it might either be expected to return the equivalent of rational? or just return true if an object was detected with an internal representation of a fraction. A nice set of macros to check for numbers of a specific internal representation could be (names are just given as examples): SCM_FIXNUM_P (currently named SCM_INUMP) SCM_BIGNUM_P (currently named SCM_BIGP) SCM_FRACTNUM_P SCM_FLOATNUM_P (currently named SCM_REALP, which is confusing) SCM_FLOATCPLXNUM_P (currently named SCM_COMPLEXP) while a nice set of macros for testing for a mathematical meaning could be (names are probably acceptable): SCM_EXACT_P SCM_NUMBER_P SCM_INTEGER_P SCM_RATIONAL_P SCM_REAL_P SCM_COMPLEX_P In the long term, we should rethink our current set of confusing names. For the short term, we should at least avoid to introduce more confusing terms, especially when introducing the new internal representation of fractions. Best regards Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel